Michael B McIlrath <MBM@MIT-XX.ARPA> (12/01/84)
I agree. I think this was discussed a long time ago. Most people thought it was in poor taste or something, I never did quite understand the objections. What would be even better is if 4.3 or whatever comes out, and you could map say the proc table into your own space. And easily write a blazingly fast sysdpy. --mike -------
wls@astrovax.UUCP (William L. Sebok) (12/03/84)
> I agree. I think this was discussed a long time ago. Most people thought > it was in poor taste or something, I never did quite understand the > objections. What would be even better is if 4.3 or whatever comes out, > and you could map say the proc table into your own space. And easily > write a blazingly fast sysdpy. > --mike I did this to the old 4.1 BSD kernel we used to run. I made public readable the addresses in which the kernel resides on the Vax (those above 0x8000000). Doing it wasn't very difficult. I figured that since /dev/kmen was already readable here and since we have a fairly benign environment that I wasn't adding any security holes that weren't already there. I had written here a program called "display" (posted to net.sources last summer) which displayed and updated a histogram of the percent cpu usage of the top cpu using processes. A #define option was placed into display to let it take advantage of direct access into kernel memory. It did indeed run faster but not as much faster as I had hoped. It turns out that curses is not terrifically fast. Of course it is very hard to write a fast program if you want to access information in the process's user area. There is no quick way to gain access to that. Unfortunately quite a bit of interesting stuff is there. Thus ps will stay slow. On the Vax one presently has to emulate the memory manager with /dev/mem: finding the page tables and seeing if the page is in memory, doing the address translation and going to /dev/mem if it is or going to /dev/swap if it is not. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls
joe@fluke.uucp (12/09/84)
I think that one system cal UNIX has been missing for years is one to return kernel structures. Sure, /dev/kmem is a very general way to provide whatever access you want, but it is an open hole into the system and as such it is open to security problems, etc. A system call can be made much more secure and can also provide MUCH faster access to the required structures than hacking around with namelists and kmem... However, it does complicate the case of ps, etc., reading core dumps. No matter what change you propose to /dev/kmem, it is bound to break ps, pstat, etc., access to crash dumps. I really like being able to use ps on crashes, but I also dislike the speed penalty you pay for runtime-access. There must be a better (or at least faster) way! As I see it, ther is no easy solution (or free lunch for that matter). /Joe
rogers@dadla.uucp (12/09/84)
<TAKE THIS BUG!!! SPLAT! HACK!! REND!!>>>
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