Messages in this thread | | | Date | Fri, 19 Dec 1997 17:00:38 -0600 | From | Michael Elizabeth Chastain <> | Subject | Re: OFFTOPIC: binary modules, bad idea! |
| |
Hello kernel hackers,
> What goals are you proposing to solve by going using more the ELF > features? The symbols are ugly, true, but is there anything else that > you want to solve by doing this?
I want separate compilation.
Right now, if drivers/net/foo.o has an external symbol for kmalloc, it depends on include/modules/slab.ver, which is generated from mm/slab.c. So changes in mm/slab.c cause all modules to be rebuilt because type information from mm/slab.c goes into all module files.
Rules.make is a tangled mess to handle this.
> Storing the type information in a seperate ELF section is cleaner, > granted, but way ELF stores type information for use with debugging is > (a) very large, and (b) produces incomparable information if two object > files #include a different set of system header files, or #include them > in a different order.
This is true. I don't want to use 'gcc -g' to produce the type information for these reasons. I think the existing 'genksyms' or something like it provides adequate protection: one hash code per symbol.
Michael Chastain <mailto:mec@shout.net> "love without fear"
| |