Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site fortune.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!fortune!olson
From: olson@fortune.UUCP (Dave Olson)
Newsgroups: net.unix-wizards
Subject: Re: Access to kmem - System namelist - 'ps' etc
Message-ID: <4717@fortune.UUCP>
Date: Sat, 1-Dec-84 20:18:46 EST
Article-I.D.: fortune.4717
Posted: Sat Dec  1 20:18:46 1984
Date-Received: Sun, 2-Dec-84 05:30:38 EST
References: <161@dido.UUCP>
Reply-To: olson@fortune.UUCP (Dave Olson)
Distribution: net
Organization: Fortune Systems, Redwood City, CA
Lines: 25

At Fortune Systems, we took a somewhat different approach.  What we
did was to fix forever in low core the important variables (or
pointers thereto, in the case of tables such as the proc table.)

This does indeed speed up ps, pstat, vmstat, etc.  We also put the
SIZES of the various structures (user, proc, etc) in low core.
This means that (with suitable re-writing of ps, pstat, etc.) you can
even change the sizes of the structures without re-compiling all 
the utilities, as long as you are simply adding new stuff at the end.

It means a bit more work in the auto-configuration code, but since we
load drivers from prom, and the driver will have to work with multiple
releases of the OS, the driver's can't have the values compiled into 
them, and therefore have to be able to look them up in known
locations.

As a side note, the number of proc's, clists, disk buffers, etc. are
settable by a user mode program, which writes the info into an EAROM,
which is then examined by the kernel at auto-configuration, so we
absolutely CAN'T have table sizes compiled in.

	Dave Olson, Fortune Systems
	UUCP: {ihnp4,ucbvax!amd}!fortune!olson
	ARPA: amd!fortune!olson@BERKELEY