Subject: Re: new sysctl(KERN_PROC, ...) interface (was: sysinfo(2))
To: None <tech-kern@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-kern
Date: 04/16/2000 15:14:22
[ On Sunday, April 16, 2000 at 07:56:58 (-0700), Eduardo Horvath wrote: ]
> Subject: Re: new sysctl(KERN_PROC, ...) interface (was: sysinfo(2))
>
> What you need to do is provide a formal interface which provides data in a 
> specific format so the syscall wrappers can do required
> translations.  Providing raw kernel data structures along with a size does
> not help.

EXACTLY!

Since 'ps' and friends change far less frequently than kernel guts seem
to I would think the appropriate interface, if not a well-defined /proc,
would be to have a set of data structures that provide the information
'ps' and friends need and to have an interface inside the kernel that
fills them out properly.  This would mean that anyone changing kernel
structures significantly would be forced to fix that translation just to
get the kernel to compile.  This would be a "good" thing.  However I
would guess that most minor changes to kernel data structures, such as
the re-ordering of fields within a structure, or the change of size of
any given field, or the addition of any new field, or even the removal
of a field not used by the interface, would be reasonably transparent
since the compiler would be taking care of these details.

Note that /proc is in effect such an interface already, though it's not
IMO well enough defined to be immune from incompatible changes by kernel
hackers....

The only time co-ordination is required is when you want to change the
interface definition, but since that requires co-ordinating changes to
both the kernel and the user-land tools, and usually because either the
tools want access to some new/different internal information, and/or
because the kernel guys want to export some new/different internal
information, this change is a lot easier to manage.  Adding a version
identifier to the interface definition even lets you stage the
depoloyment of such a change without experiencing "undefined" behaviour.

>    You could do the same thing with kernel grovelling by ignoring
> the structure size mismatch and presuming that no existing fields have
> changed size or location.

some versions of Unix in effect did this -- it was very disturbing....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>