Path: utzoo!utgpu!water!watmath!clyde!motown!vilya!lcuxlm!whuts!att!rutgers!gatech!ncar!ames!ucsd!ucsdhub!jack!elgar!ag From: ag@elgar.UUCP (Keith Gabryelski) Newsgroups: comp.unix.wizards Subject: Re: finding the u structure in /dev/mem on SYSV (how ?) Message-ID: <222@elgar.UUCP> Date: 18 Aug 88 05:07:52 GMT References: <16837@adm.ARPA> Reply-To: ag@elgar.UUCP (Keith Gabryelski) Organization: Elgar Corporation, San Diego, CA Lines: 52 In article <16837@adm.ARPA> rbj@nav.icst.nbs.gov (Root Boy Jim) writes: >? From: fsg@holos0.UUCP (Frank Glass) > >? I am writing a routine to list UNIX processes and their respective ages. >? I need for the source to be reasonably portable across System V (or at >? least USG) breeds of machines. Getting to the proc table seems simple >? and consistent: use nl() to get proc address from /unix, seek to that >? address Kay... You could also save the proc address in a file so you won't have to do the nlist every time. Check the access time of your proc-address-file against the kernel file and if the kernel has been modified recently, re-nlist the kernel. >? in /dev/kmem and read the first element in. Any macros I need seem to >? be in >? sys/sysmacros.h. The next problem is getting to the u structure in >? /dev/mem. What you want to do is read in the entire proc array so you don't have to deal with proccess-exiting contigencies. Then for each idividual proc entry check to see if the process is swapped out. If it is, look at the p_swaddr and compute the u struct location in /dev/swap. If the process is not swapped then p_addr is used to compute the address of the u struct in /dev/mem. Depending on the port and whether your system uses pages or whatnot then p_*addr's may point to block numbers or page table entries or whatever. Usually there is enough information in the header files to go from here. I have a finger program written for SCO Xenix 386. It has been ported ot the 3b1 and I started porting to the 3b5 and the 286 Xenix machine. I will send it to you if you would like. Send me mail. >Just a side issue, but what if things change during your poking around in >/dev/{kmem,swap}? How do ps-like programs deal with such things? Usually, you want to read in the entire proc array then read in each individual u structs. Hopefully most of the process will stay put during these reads. If the u struct does not look valid then I think the most reasonable thing to do is discard the current process. It probably exited during your reads or did something nasty. Pax, Keith -- "If green is all there is to be, then green is good enough for me" - ktf [ Keith ] UUCP: {ucsd, cbosgd!crash, sdcsvax!crash, nosc!crash}!elgar!ag [Gabryelski] INET: ag@elgar.cts.com ARPA: elgar!ag@ucsd.edu