lkml.org 
[lkml]   [1997]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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"

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.039 / U:0.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site