Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.6.2.17 $; site uokvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!mhuxn!houxm!ihnp4!inuxc!pur-ee!uiucdcs!uokvax!jab
From: jab@uokvax.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Access to kmem - System namelist - '
Message-ID: <6200035@uokvax.UUCP>
Date: Tue, 18-Dec-84 00:11:00 EST
Article-I.D.: uokvax.6200035
Posted: Tue Dec 18 00:11:00 1984
Date-Received: Fri, 7-Dec-84 01:13:53 EST
References: <161@dido.UUCP>
Lines: 17
Nf-ID: #R:dido:-16100:uokvax:6200035:37777777600:736
Nf-From: uokvax!jab    Dec  4 23:11:00 1984

/***** uokvax:net.unix-wizar / fortune!olson / 11:54 pm  Dec  1, 1984 */
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.)
/* ---------- */
Yet another way (one that I don't happen to agree with) that one Unix
does it is to have a magic system call:
	getsyms(not its real name) returns the values of the addresses
	of the proc/inode/... tables.

I believe that people at the Purdue/ECN (where I first heard about this
kind of thing) realized a significant increase in speed when they wrote
"/dev/proc" and "/dev/inode" as specialized cases of the "/dev/kmem" code.

	Jeff Bowles
	Lisle, IL