>OK; so far, we have two potential solutions:
>
>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)
>
>2) Maintain pointer to kernel on disk
>   PROS: minimal kernel memory impact
>   CONS: kernel image may be unavailable after boot, and may have been
>         moved.

I'm not too fond of 2: it is a partial fix, and especially the 'moving the
running kernel' bit is one of my major gripes with the current situation.

What's wrong with providing a kernel build option to not keep the symbol
table, and fall back to the old /dev/kmem approach, if you're low on
memory? Also, I'd like to see by how much the wired kernel size increases
before even deciding such a build option is worthwhile. I have a hard time
believing it'll grow by more that 1K, and even a sun3 can cope with that.
But I might be way off bat here...

Cheers,
					-- Bert Driehuis

------
Bert Driehuis                 God, grant me the serenity to accept the things
driehuis@playbeing.org        I can't change, courage to change the things I
                              can, and the wisdom to know the difference.