Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!mit-eddie!smh From: smh@mit-eddie.UUCP (Steven M. Haflich) Newsgroups: net.unix-wizards Subject: Re: Access to kmem - System namelist - 'ps' etc Message-ID: <3365@mit-eddie.UUCP> Date: Fri, 28-Dec-84 12:41:34 EST Article-I.D.: mit-eddi.3365 Posted: Fri Dec 28 12:41:34 1984 Date-Received: Sat, 29-Dec-84 03:12:03 EST References: <126@dadla.UUCP> <1587@psuvax1.UUCP> Reply-To: smh@mit-eddie.UUCP (Steven M. Haflich) Organization: MIT, Cambridge, MA Lines: 20 These various ideas to make kernel structure accesses more efficient are certainly well motivated, but I will never understand the current propensity for installing less-than-absolutely-necessary hacks in the kernel. I paraphrase a theorem from DMR's [?] dimly-remembered but venerable paper on the implementation of Unix: The kernel is [ought to be] little more than an I/O multiplexer. My corollary: Every byte of kernel code implementing unnecessary or little-used features is a byte permanently unavailable for buffer cache and paging user code. Historically the kernel namelist problem has been elegantly solved many times by various commands which, upon first invocation after a reboot, create a predigested symbol table file somewhere (like in /tmp, which gets cleared out by every reboot). It seems to me that the right thing to do is to standardize this procedure, run it just once per boot from /etc/rc, and be done with it. Existing tools are perfectly adequate: nm -pg /vmunix | fgrep -f /interesting_symbols > /kernel_symbols The resulting /kernel_symbols file is quite short and can be read and parsed trivially and quickly using scanf. The mechanism seems elegant and Unixy, something becoming rare in these days of .5MB kernels.