haahr@phoenix.Princeton.EDU (Paul Gluckauf Haahr) (10/26/88)
Steve Summit suggests that, using nlist() and /dev/kmem are noth not portable and a very bad sort of intermodule coupling. In article <3978@encore.UUCP> bzs@encore.com (Barry Shein) writes: > I agree, actually there's a more general problem of returning all > sorts of info which is currently groveled out of nlist() and > /dev/kmem. Encore has a syscall in their 4.x which returns various > kernel data structures but it hasn't exactly wowed the unix community > (nor should it have, it needs redesign.) One problem is that with > parallel processors your chance of getting a good copy of a data > structure by copying out of /dev/kmem go down considerably. > > Someone should propose something, maybe a bunch of ioctl's on > /dev/kmem. using ioctl() is probably a bad approach. the interface is rather baroque, and it hard to tell from looking at a call what is going on. note the difficulties the posix committee had (has?) with ioctl(). if we want something that melds into the "unix philosophy," a virtual file system (similar to /proc) is probably approriate. i would suggest a /ksym file system, where opening /ksym/averun give a file of length (sizeof averun) and the contents are the contents of the kernel variable. implementation of such a device is trivial, provided the kernel has access to its own symbol table. this can be provided trivially inside a linker or by a post-linking pass (which was what i had to do). providing a kernel with its own symbol table is useful, especially for interpreting stack traces. i implemented this approach in small kernel for diskless workstations written for an operating systems course. [ this operating system is not unix, but was influenced by unix and plan 9 ] i implemented the feature after most work on the operating system was done, though i should have implemented it earlier as it was a tremendously useful debugging device. /ksym would not solve problems about incompatible byte orders across networks, so only reading the local kernel would be guaranteed to work. insuring atomicity of reads in /ksym would probably be tough in a multiprocessor, though certainly not impossible. ensuring consistent state across reads of different /ksym structures would put a burden on user programs, suggesting that a /proc would be needed for ps, a /mount would be needed for df, etcetera. comments? suggestions? followups?