Finding Open Files

[The devil himself]

I've always thought that it would be useful to have a command capable of
displaying all of the system's open files (probably broken down per
process).  Well, I've finally gotten around to giving it a shot.  And you
guessed it, I'm having some minor problems.
(Oh yes, I better mention that I'm working with SunOS 4.0).

My primary concern is with the "dynamic" nature of the kernel data
structures that need to be read.  It would seem to me that there is no
way to prevent the kernel from changing these values while you read them
without potentially creating a deadlock situation.  So, I am assuming
the best that can be done is to minimize the time over which kernel
data is being sampled.  Of course, I can always fiddle with my process
priority - but that's rather obvious.  Perhaps, of equal importance,
is how the information is read.  I am trying to read the kernel data
in the most time-efficient manner possible (that I can think of), and this
is where I am having some trouble.

Here, very briefly is what I am doing.
First I obtain the process table entry and u-area for the process being
scrutinized, and then I do the following: 
(1) get the values for: nfile, file, ninode, inode
(2) read the entire file table
(3) read the entire inode table
At this point, I thought that I had all of the information I needed.
The u-area contains a "list" of open files and u.u_ofile[x] would
tell me which entry in the file table to examine.
>From there, I grab file.f_data which points to a vnode (assume no sockets).
Now since vnodes are stored within their corresponding inode, it's
easy to pick off the dev/inumber pair of the file.

But it ain't so.  It works fine for regular files, but things crash and
burn when I hit a character/block special file.  It appears that
the f_data member of the file table entry is pointing to a vnode structure
located inside an lnode (or at least some entity outside of the inode table).
The problem is that there doesn't seem to be any lnode table per se.
(I imagine that I would encounter the same problem with files accessed
via NFS (assuming that they use rnodes instead of inodes)).
Does this mean I have to do a bunch a reads jumping all over the place,
just to pick off the lnode (and rnode?) entries?  Or is there a "sneaky"
way of reading all the lnodes/rnodes at once?

Do you see any other problems with what I'm doing?

Any other comments, pointers, or criticisms are welcome.
Thanks in advance.

---
Mike Adams
mdadams at surya.uwaterloo.ca
mdadams at surya.waterloo.edu
{decvax,utzoo,uunet}!watmath!surya!mdadams