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

For a proper LKM interface, you want to have a specific set of symbols
which are exported from modules in the kernel (either loaded or
compiled in), and you _do not_ want to give modules access to anything
other than those symbols.  Since i can see no easy way to do that via
the same mechanism that would do 'whole' symbol tables, i'd say that
the whole symbol table approach could not apply to a proper LKM
interface.

Yes, it would apply to the existing LKM interface, but i think you'll
find it hard to argue that the existing one is a good one.  8-)


Also, while i'm at it...  8-)

The case previously discussed re: install kernels isn't quite as odd a
case as it might seem...

Say i've got a machine which automatically detects the boot (root)
device and sets the swap device by default to the 'b' partition of the
root device.  'generic-ish' kernels like that aren't too uncommon
on ports that can do that.  In fact, i run nothing else (except to
test 8-) on most of my alphas...

All would work nicely when booting off my hard drive, because i've got
a swap partition in the 'normal' place.  But say i want to put the
kernel on a floppy, so i could boot off of it if the kernel on my hard
drive gets roached...  Well, all of a sudden i don't have that swap
device around any more, and life becomes a Lot Harder if i'm on a
small-memory machine.

Also, at some point in the future, the 'magic' of automatically
detecting a default swap device may go away...  And if it does, then
the system will have to end up doing a lot more with the symbol table
around (e.g. run a fair-sized, but not large, chunk of /etc/rc).



All things considered, i consider an approach like:

	(1) pass kernel name (if known) to kernel at boot time,

	(2) kvm_mkdb during rc with that kernel name.

Sure, if people are monkeying about with their kernels in single-user
mode, they can lose, but they did something to make themselves lose.
Also, if their kernels aren't in their file system they lose, but
(having done a bunch of diskless booting) i'm not sure i'd call this
something to worry about.

Remember that kvm-using programs (if written properly and not passed
'-N') will try to use the kvm database as a symbol table for the
running kernel (if the kvm db matches the running kernel).  If the kvm
database is set up at boot, things should just work, even if the
kernel is moved.



cgd