Re: A module bug in 2.2.1?

Marcin Dalecki (dalecki@cs.net.pl)
Thu, 04 Feb 1999 23:26:03 +0100


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/