Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site heurikon.UUCP Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!edsel!bentley!hudson!ihnp1!ihnp4!zehntel!hplabs!hao!seismo!uwvax!heurikon!perry From: perry@heurikon.UUCP (Perry Kivolowitz) Newsgroups: net.unix-wizards Subject: Re: Access to kmem - System namelist - 'ps' etc Message-ID: <129@heurikon.UUCP> Date: Sun, 2-Dec-84 03:27:55 EST Article-I.D.: heurikon.129 Posted: Sun Dec 2 03:27:55 1984 Date-Received: Tue, 4-Dec-84 19:45:01 EST References: <161@dido.UUCP> Organization: Heurikon Corp., Madison WI Lines: 59 > 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. > > Think of the advantages: > > 1. "Anyone" could write their own "ps" without being superuser with > X-ray vision on /dev/*mem etc. > > 2. You could control access to the various bits as you wished - no > worrying about people monitoring clists for passwords etc. > > 3. Ps would run a lot faster not having to pick its way through the > symbol table of /unix. > > 4. Ps (and other such programs) would not have to know if the current > system wasn't /unix. Should be an environment variable at present > anyway. > > Ok - what have I overlooked..... Start flaming now!! > > -- > John Collins > It has been said often that the best ideas are the ones which are simple. This seems to me to be an effective yet simple way to break key data structures into the open. The idea of doing so is not a new one to this news group, numerous persons voiced arguments both for and against such a tack. (I can't recall any of the arguments against...someone want to re- fresh me?) To my mind the most important of the points listed by John is making programs which currently require the name-list of the currently executing o.s., name-list independent. It's a good idea - and fits in well with established UNIX* philosophy. Another point (though pretty obvious, is well worth making) is that im- plementing /dev/kmem/data-structure files will not in any way make the current ps, df, etc incompatible. Not a point to be dismissed lightly. Related topics: Research at Stony Brook University; Viewing data struc- tures in the kernel as relations and operating on them as such. ``Processes as Files'', Thomas J. Killian, 1984 Summer Usenix Conference. Perry S. Kivolowitz Heurikon Corporation ----------------------------------------------- *UNIX is a trademark of a once proud but now morally destitute company.