Subject: Re: kernel symbol tables (was Re: vmstat, iostat etc no longer
To: Mike Long <firstname.lastname@example.org>
From: Bert Driehuis <email@example.com>
Date: 11/15/1996 08:34:53
>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
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...
-- Bert Driehuis
Bert Driehuis God, grant me the serenity to accept the things
firstname.lastname@example.org I can't change, courage to change the things I
can, and the wisdom to know the difference.