Messages in this thread | | | Date | Thu, 04 Feb 1999 23:26:03 +0100 | From | Marcin Dalecki <> | Subject | Re: A module bug in 2.2.1? |
| |
Ulrich Drepper wrote: > > Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be> writes: > > > As > > > the purpose of the shell is to invoke insmod on unix.o (modprobe uses > > > system() to facilitate shell expansion of entries from modules.conf), the > > > module is finally inserted and processing continues. > > I don't know the modutils package, but if as you write the sole > purpose of using the shell is to use the shell expansion there is a > better way: wordexp. Also new in glibc 2.1.
Since I wrote modprobe and depmod I know at least what they where doing until the 2.1.45 relase. Thereafter RedHat fucked them up, without even giving me a single notice. I can assure you that I have never coded something that stiupid into it...
If somebody deserves to change them in any usefull way then please do the following:
Elliminate the syscall from, modprobe which is requesting insmod as a separate command! insmod should be fully integrated into modprobe and modprobe should be the only app called by kmod.
I'm certainly not going to do it myself. I'm not going to work for RedHat without contract anylonger. In esp. since I'm considering the whole design of the module system to be brain dead in Linux. (Admittedly it got a bit better with 2.2. Anything before was just terrible.)
- Why the hell is there any need to hold the symbol tables of the kernel in unswappable kernel memmory with the strings describing the call addresses there?
- Why the hell is there something like MODVERSIONS --- that's just giving you a placebo of upgrade security --- nothing more.
- Why the hell do we handle pure object files instead of some 'prelinked' simple special purpose module object format. All standard kernel symbols could be resolved by depmod without even calling the kernel itself back. The prelinkage could be done esaly by using the bfd and objects libraries in a generic way, without the need of a special purpose ELF format reading library in the modutils themself.
- Why the hell do we store the modules in the file system instead of a special purose database (read: single file), which would facilitate it to load them from a contignous block area on the disk really in front of the init process. (The system map should be stored at the same place.)
I could continue but who cares anyway...
--Marcin
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |