Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!att!occrsh!uokmax!rmtodd
From: rmtodd@uokmax.UUCP (Richard Michael Todd)
Newsgroups: comp.unix.wizards
Subject: Re: GNU os suggestions -- system data interfaces
Message-ID: <3307@uokmax.UUCP>
Date: 5 Jun 89 22:09:37 GMT
References: <1344@marvin.Solbourne.COM>
Reply-To: rmtodd@uokmax.UUCP (Richard Michael Todd)
Organization: University of Oklahoma, ECN
Lines: 52

In article <1344@marvin.Solbourne.COM> dce@Solbourne.com (David Elliott) writes:
>Two items that I find particularly annoying are getting kernel data
>values and handling system files.
  Getting kernel data values isn't too much of a problem (once you master
nlist and friends), though as UNIX is currently implemented it's extremely
ugly.  The main problem I seem to run into is figuring out just what kernel
variable you need, what format it is in, and what it means once you've got
it.  The closest thing you find to documentation is groveling through 
/usr/include/sys and seeing if anything interesting seems to be useful.
(Then you get to guess which other include files /usr/include/sys/whatever.h
needs to have precede it.  I've often wished for all include files to 
clearly state in a comment: NEEDS sys/types.h, sys/page.h, etc..)
Anyway, what I'm saying is that to a large extent the existing kernel 
internals need to be documented. 
  Granted, a better interface to reading kernel internal variables and
structures would be nice, but unless the variables are documented it 
won't do you much good.

>The nlist interface to the kernel is a major hassle for a number of
>reasons.  First of all, I find that in a lot of development
>environments, the kernel that is running is not /vmunix or /unix, but
>is some other item.  Secondly, people often want to know things like
>the load average without having to make their programs setuid (or
>worse, they get root permission and start playing system god without
>having enough experience).  Finally, sizes of data structures change,

Well, really such programs ought to be setgid kmem (or whatever group
owns /dev/kmem), but still your point applies--it makes it impossible for
Joe User to write such programs himself, and is a pain even for Joe Sysadmin.

>yet there is no interface for getting these sizes, and in heavy
>development environments, you can't even guarantee that your sys header
>files match the kernel (or any kernel, for that matter).  Programs like
>ps would be a lot more useable in the face of kernel programmers if
>this data were available at run-time.
  Agreed.  It would be nice if there was an improved version of nlist that
could read not only the address of the kernel data structure, but the type
and size as well (presumably the kernel would be compiled with -g), and 
automatically read in the right amount of data.
  Of course, an even better approach is to have some system call to 
fetch kernel data yourself, without requiring that /dev/kmem be accessible.
Encore has such a system call, called inq_stats; ps and its friends are 
implemented using inq_stats, and mere users can write their own ps-like
programs for collecting data on processes.  Of course, the flip side of this
is  that if you want some information that isn't one of the types inq_stats
will give, you're SOL (e.g. as far as I and a friend of mine can tell, there's
no way to tell from inq_stats data if a process is swapped out.)  Still,
such a call is useful.
-- 
Richard Todd   rmtodd@chinet.chi.il.us  or  rmtodd@uokmax.ecn.uoknor.edu  
                                    aka     ...!sun!texsun!uokmax!rmtodd
"Never re-invent the wheel unnecessarily; yours may have corners."-henry@utzoo