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