Le Sun, 16 Nov 2003 12:13:57 +0100 (MET)
ragge@ludd.luth.se a ecrit :
> > 
> > I would like to commit the attached patch, which actually solves the
> > problems outlined in kern/21256.
> > 
> I assume you mean 21526 :-) Oh, that was an old one.  I haven't seen
> it before (maybe therefore I haven't taken any care of it :-)

Good thing I didn't CC'd GNATS.

> > Currently, when support for /dev/ksyms is compiled in, ksyms_addsym
> > will shift every symbol value to make the symbol tables appear as one
> > when reading from /dev/ksyms.  But this makes the value of the symbol
> > invalid when used in the kernel, and lead to crashes when loading a
> > LKM module that uses modules from other LKMs.  The fact that the
> > kernel's symbol table appears as the first one means the kernel
> > symbols values are not shifted, otherwise loading any LKM would crash.
> > 
> Yeah, you discovered a thinko from my side here.  I tested it by 
> loading one module that depended on one other, which worked (probably
> because the correct phase of moon etc).

It can work, as long as the kernel symbol table is large enough to let the
offset in, or something like that.  But that's just luck.

> > most importantly to ksyms_getval() to indicate whether the request
> > comes from the kernel or the userland.  It also adds to handy defines
> > as wrappers around the new ksyms_getval.  Note that this change will
> > require a kernel version bump.
> > 
> Why? Your changes does not affect userland, and the only usage of 
> those routines are the one you changed.

LKMs can use ksyms_getval: it can be useful to know if something is
compiled in or not at runtime, like support for BPF for an Ethernet
driver, or for a crypto algorithm for, say, a PPP compressor.

[...]
> > Comments?  I know the LKM part is just a hack, but not by much more
> > than what we do to load LKMs, and a well designed in-kernel linker
> > mechanism will solve the issue.  In the meantime, I think it is useful
> > to be able to access LKM symbols at that precise time.
> > 
> When looking through your patches it seems good.  As you wrote, an
> in-kernel linker would take care of much of the problems (and also would
> cause much of the ksyms code to be removed/changed).  I say check it in.

Ok.  Is there anything else pending that would require a version bump?

-- 
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"Feels like I'm fiddling while Rome is burning down.
Should I lay my fiddle down and take a rifle from the ground ?"
Leigh Nash/Sixpence None The Richer, Paralyzed, Divine Discontents, 2002.