Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 11/03/84 (WLS Mods); site astrovax.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!astrovax!wls From: wls@astrovax.UUCP (William L. Sebok) Newsgroups: net.unix-wizards Subject: Re: Access to kmem - System namelist - ps etc Message-ID: <502@astrovax.UUCP> Date: Sun, 2-Dec-84 17:08:39 EST Article-I.D.: astrovax.502 Posted: Sun Dec 2 17:08:39 1984 Date-Received: Tue, 4-Dec-84 06:19:33 EST References: <6244@brl-tgr.ARPA> Organization: Princeton Univ. Astrophysics Lines: 30 > 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