> >> 1) Use kernel symbol table in memory.
> >>    PROS: guaranteed to be correct, can include LKM symbols
> >>    CONS: kernel bloat, bad for low-memory machines (sun3)
> 
> > I would argue that there's a fallacy here.
> 
> > Given a proper LKM interface, loadable modules should not need, and
> > should not be given, access to all of the kernel's symbols or the
> > symbols of other modules.
> 
> You're Confused (tm).  The argument is that the in-memory symbol table
> could include symbols from LKMs, in addition to the symbols from the
> basic kernel.  I don't really know why this is important, but unless
> I'm completely misunderstanding things, Mike was not arguing that the
> LKM interface could use this symbol table.

So, i figured that he wasn't arguing for just that, since i couldn't
figure out any reason why it would be important/useful, except in the
context of loading other LKMs...


> If I'm not calculating wrong, the symbol table on a sample i386 kernel
> is about 52K in size ("ls -l" reports 1023974 bytes, "size" reports a
> dec field of 97171).  Maybe you lose twice that, or 100K, on an Alpha.
> Sure, on a 4MB machine with no swap space, this is going to hurt your
> multi-user performance, but I don't think it's going to make it
> impossible to install the machine, rescue the system, or carry out the
> first part of /etc/rc.

On the alpha it's 120-150k (by the same metric).


> I'm for the more robust approach.

I'm not saying that it's necessarily bad,w just that the corner cases
shouldn't be overlooked, and that logically incorrect justifications
shouldn't be given as to why it's a "good solution."


cgd