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

Getting back to the main issue:

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.

I'm for the more robust approach.  If you're really paranoid about
that lost memory in the corner cases, there can be both a kernel
config option and a boot loader option to disable symbol loading.