getting the load average

[Paul Gluckauf Haahr]

Steve Summit suggests that, using nlist() and /dev/kmem are
noth not portable and a very bad sort of intermodule coupling.

In article <3978 at encore.UUCP> bzs at 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?