Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!decvax!wivax!cadmus!harvard!seismo!brl-tgr!tgr!rogers@dadla.uucp From: rogers@dadla.uucp Newsgroups: net.unix-wizards Subject: Re: Access to kmem - System namelist - ps etc Message-ID: <6540@brl-tgr.ARPA> Date: Sun, 9-Dec-84 06:31:50 EST Article-I.D.: brl-tgr.6540 Posted: Sun Dec 9 06:31:50 1984 Date-Received: Thu, 13-Dec-84 01:56:30 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 49>> What I'd really love to see is a system call which you could get the information needed for ps. This would simplify the dickens out of "ps", "w", and other programs which you need to find out about non-children processes (like an auto-logout based on time program we have that was hacked from the "w" code...). Anyway, if the complete system call is not possible, I would like a cleaner interface into /dev/?mem. Perhaps a system call which you could use to get addresses of various things rather than just knowing how big items are, and looking from the beginning of tables (or however ps handles it). This would make those tables whose size is determined at boot time a breeze to look thru, and really wouldn't cost that much. Something like: getaddrof(item, addressp) int item; char *addressp; "item" could be selected from a list of defines, and we would supply a char pointer to stuff the address into ("addressp", above). The call should only good for the super user, so users can't go looking at other people's data (possibly getting a password...). Well, enough of the strangeness. I suppose it's only wishfull thinking on my part. I guess the handstands one must go through is really job security. I mean, gosh.. then EVEN the unskilled could write a portable "ps"... :-) -Roger UUCP: HOST!tektronix!dadla!rogers Where HOST is any one of: masscomp,decvax,allegra,uf-cgrl,mit-eddie,mit-ems, uoregon,psu-cs,orstcs,zehntel,ucbcad,ucbvax,purdue, uw-beaver,reed,ogcvax,ihnp4,tekred,minn-ua,cbosg CSnet: rogers%dadla@tektronix ARPAnet: rogers%dadla%tektronix@csnet-relay