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