hamilton@uiucuxc.UUCP (12/03/84)
> /* Written 11:26 pm Dec 1, 1984 by john@dido in uiucuxc:net.unix-wizar */ > /* ---------- "Access to kmem - System namelist - '" ---------- */ > Why do so many commands such as 'ps', 'ipcs' and what have you have to use > the /unix namelist to find out kernel addresses? > > I'd like to propose subdivisions of /dev/kmem, thus > > /dev/kmem/proc for the process table > /dev/kmem/inode for the inode table > > and so forth. Implementation would be trivial. > /* End of text from uiucuxc:net.unix-wizar */ i think whitesmiths' idris adopted this approach. if i remember right, they had a /dev/proc, /dev/user, etc, all minor devices of the same major device. wayne ({decvax,ucbvax}!pur-ee!uiucdcs!uiucuxc!)hamilton
henry@utzoo.UUCP (Henry Spencer) (12/08/84)
I hate to throw cold water on the widespread cries of joy, but I hope
everyone realizes that programs which "know" about the kernel tables --
however they gain access to them, /dev/kmem or whatever -- are hopelessly
unportable. They may also be unreliable, due to race conditions.
It is indeed a blemish that there is no safe, implementation-independent
way of getting this information. But it's not impossible to devise such
a thing, guys; has anyone bothered to try? Bell Labs's "/proc" is a good
first step.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrygreenber@acf4.UUCP (12/12/84)
<> My god!!!! Somebody else remembers TOPS-10..........
jab@uokvax.UUCP (12/18/84)
/***** 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