Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83 (MC830707); site sara70.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!mhuxn!houxm!ihnp4!zehntel!hplabs!hao!seismo!mcvax!sara70!gijs From: gijs@sara70.UUCP (gijs) Newsgroups: net.unix-wizards Subject: Re: Access to kmem - System namelist - 'ps' etc Message-ID: <253@sara70.UUCP> Date: Mon, 3-Dec-84 19:07:09 EST Article-I.D.: sara70.253 Posted: Mon Dec 3 19:07:09 1984 Date-Received: Thu, 6-Dec-84 05:40:49 EST References: <161@dido.UUCP> <129@heurikon.UUCP> Organization: SARA, Amsterdam, The Netherlands Lines: 38 In <161@dido.UUCP> john@dido.UUCP (John Collins) writes: >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. And what about the X-ray vision on /dev/swap? >2. You could control access to the various bits as you wished - no > worrying about people monitoring clists for passwords etc. The best thing to do is *not* to give any access to system tables. Accessible tables will soon be used by many application programs which prevents format changes of such tables. And even if you restrict access to the super user it would be a bad idea. Adding some feature to a ps-like program should never mean adding another "view" to a kernel driver. There are also practical problems: - how do you interpret pointers to things? - what to do if you need many tables (=files) open at the same time on small machines? >3. Ps would run a lot faster not having to pick its way through the > symbol table of /unix. I suspect that ps spends most of its time reading swap files. Gijs Mos, Free University Dept of Biology Amsterdam {seismo,decvax,philabs}!mcvax!sara70!gijs