finding the u structure in /dev/mem on SYSV (how ?)

[Keith Gabryelski]

In article <16837 at adm.ARPA> rbj at nav.icst.nbs.gov (Root Boy Jim) writes:
>? From: fsg at 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 at elgar.cts.com                 ARPA: elgar!ag at ucsd.edu