daemon@watale.waterloo.edu (The devil himself) (09/05/88)
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@surya.uwaterloo.ca mdadams@surya.waterloo.edu {decvax,utzoo,uunet}!watmath!surya!mdadams