davidb@Pacer.UUCP (David Barts) (02/06/90)
In the OSK technical manual, it is mentioned that the V_Paths offset in static storage is a "Linked list of open paths. This is used by the kernel to determine if a non-sharable device is already in use." I would assume that V_Paths is a pointer to the first item in the linked list and that a nil (zero) pointer implies that there are no paths open to the device (and vice versa). Thus one can determine if any process has a device open by examining V_Paths in the static storage area and testing for a zero value. Unfortunately, this is only a guess. Is there anyone on the net who can confirm or deny this? (If this is not the case, then how does one use V_Paths to see if nobody has a device open?) -- David Barts Pacer Corporation davidb@pacer.uucp ...!fluke!pacer!davidb
kim@mcrware.UUCP (Kim Kempf) (02/09/90)
In article <272@zircon.UUCP> davidb@Pacer.UUCP (David Barts) writes: >I would assume that V_Paths is a pointer to the first item in >... >Unfortunately, this is only a guess. ... Your assumption is absolutely correct. The root of this list is (indirectly) based in the Device Table. (Devicetbl)->V_stat in the device table entry points to the driver's static storage. (sysioStatic*)->v_paths in the driver's static storage is the root of the list of open path descriptors on the device. Finally, then (union pathdesc *)->pd_paths is the 'next' pointer in the linked list. The above variables and structs are the C definitions. You'll have to figure out for yourself the assembly language defs. RBF uses the device open list to maintain the record-locking information. SCF used the list to handle HANGUP. PKMAN uses the list to keep track of who's using the slave side of the pseudo-keyboard. This list is automagically maintained by IOMAN for the convenience of the file managers (but sometimes the drivers can make use of the list, too.) Another bit of OS-9 I/O internals trivia related to this matter. Notice in the path descriptor there is pd_cnt and pd_count. The number of paths linked into this list is maintained in pd_count. Comments related to pd_cnt indicate "/* number of original open images */". What this is actually trying to say is that this variable is the original (read: historic, archaic) vestige. Notice that the value is only 8-bits. pd_count's comment reads "/* actual number of open images */". This means that this is the actual count and the true object for filemanagers to look at to determine the number of open images (read: dup()) on this path. pd_cnt and pd_count both track each other up to 255, then pd_cnt stops and pd_count takes over, counting up to 65535 open paths. When pd_count goes below 255 again, pd_cnt starts to decrement again. Thus, pd_cnt tells the number of path dups 0-255, where 255 means at least 255. Any code concerned (mostly filemanagers) should use just pd_count, as pd_cnt is a relic from the 6809 ancestry. There is an anecdote associated with this. I remember in the early days of OSK (OS-9/68k), when memory started becoming vast (greater than 128k) we set out see how many processes OSK could fork an run before falling over and croaking. Using something similar to Peter Dibble's "rabbit program", we'ed start that running forking hundreds of processes. It was fun to run 'procs' and try to look at the rapidly changing process table list. Occasionally, the standard paths display would get strange: 183 10 12.100 128 4.00k 0 w 0.60 0:16 roger <>>>term 184 10 12.100 128 4.00k 0 w 0.60 0:16 roger <>>>term 185 10 12.100 128 4.00k 0 w 0.60 0:16 roger <>>term 186 10 12.100 128 4.00k 0 w 0.60 0:16 roger <>>>term 187 10 12.100 128 4.00k 0 w 0.60 0:16 roger <>>>term 188 10 12.100 128 4.00k 0 w 0.60 0:16 roger <>>>term Notice that process 185 seems not to have either standard output or error open. This was caused by the single path open to /term to have its pd_cnt wrap around to zero (3 dups of the /term path per forked process). A bit of clever detective work by Robert Doggett and his equally clever upwards compatable solution (as described above) yields pd_count as we know it today... -- ---------------- Kim Kempf, Microware Systems Corporation {sun,uunet}!mcrware!kim My employer guffaws at my opinions....