Re: A module bug in 2.2.1?

Alan Cox (alan@lxorguk.ukuu.org.uk)
Thu, 4 Feb 1999 23:43:10 +0000 (GMT)


> 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...

Lies like that deserve a direct response.

modutils is mostly done by Richard Henderson (originally Tamu now
Cygnus). Other contributors are Randy McCaskill (comm-data), the esteemed
sparc64 guru Jakub, Tom Dyas (sparc32 hacker), Michael Chastain (config
file wizard), etc ...

Not a single vendor involved. Modutils is maintained by the community.

Why don't you go and scream at the people who maintain the package, is
it perhaps because you'd look the part you really are if you spent a day
on linux-kernel howling at the volunteers who did the real work to keep
modutils happy ?

> 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.

Go and read Kernighan's stuff on Unix and _tools_.

> - 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?

Thats actually a good question. You could keep it in a userspace database
and import the kernel symbols.

> - Why the hell is there something like MODVERSIONS --- that's just
> giving you a placebo of upgrade security --- nothing more.

Almost all incompatibilities get caught by this. The alternative is to
tie to version information only - which is even worse. During 2.1.* we've
had a whole pile of build options affect critical object size happenings. Im
just hoping most of them got nuked for 2.2.

> - 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.

Tools dear boy, Tools. I can objdump pure object files. I can use libbfd
to handle them and symbol resolution. I don't have to write my own half
baked solution for it.

In addition a "simple module format" doesn't work on some platforms. I doubt
your vision of such things includes half word relocates, MIPS gp relative
relocations, ARM 26bit relocations - does it ?

> 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.

A special purose ELF format reading library. You mean libbfd. Good isnt it.
Tools again. The entire insmod/rmmod is 3000 lines including back compatibility

> - 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.)

Because
a) I want to be able to use standard tools on them
b) The ram disk (initrd) solves this problem while solving some
hundreds of other problems like bootstrapping strange diskless
setups. It comes for free - tools tools and more tools

> I could continue but who cares anyway...

Except for the "why arent the symbols in pageable space" come back when you
have something _worth_ saying.

Alan

-
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/