[ On Thursday, April 12, 2001 at 01:08:51 (-0700), Todd Whitesel wrote: ]
> Subject: Re: Kernel include files proposal
>
> There are four classes of headers, I think:
> 
>     1. userland definitely needs them. (ioctl() descriptions for example)
>     2. only low-level userland needs them. (disklabel, installboot, etc)
>     3. only 3rd-party LKM's need them. (which are these? we need to know!)
>     4. nothing in userland needs them.

That's a pretty good breakdown and I like it, BUT......

> Please do not argue that all of userland needs to see all of the kernel
> headers.

Well, OK....

> If they actually _used_ them all, we'd never be able to revise
> the kernel's internal API's and that would stifle kernel evolution.

To be blunt that's pure and total BS.

(to pick nits too, "internal API" is an oxymoron)

Note also that if the system's own utilities use kernel stuff then
anything and everything can be changed (in lock step, of course) at
will.

> The value of this project is not in breaking 3rd party software; it's in
> finding out which headers we have to keep exporting in order to avoid
> breaking 3rd party software.

That's BS too (and part of what's seriously wrong with NetBSD)!

> Once we know what that list is, we can work
> on finding better ways to expose the functionality so that 3rd party code
> does not need to use the direct kernel headers any more.

While it may be true that there are some kernel structures which simply
cannot be used by any userland program (because they're too volatile
across context switches, etc.), 
 
The only things that SHOULD NOT be changed so as to protect the
viability of 3rd-party software across releases are *published*
interfaces.  By "published" I mean those in NetBSD's own documentation.
I suppose one could argue that unpublished but de facto standard
interfaces inherited from previous generations of Unix should also be
treated as "published" too.

Any software (either delivered with the system or supplied to users by a
3rd-party developer) that uses un-published kernel internals through the
likes of /dev/kmem (or any other half-baked interface like that), or is
intended to integrate into the kernel as either a device driver, or LKM,
must always be considered to be on its own w.r.t tracking changes in
kernel internals from release to release.  If the kernel internals
change and break it across releases then it must be updated or die.  Any
project which attempts to keep its internals in some fixed state is
going to die of strangulation at its own hands.

Note I did not say "MUST NOT" above w.r.t. published interfaces.  There
should be no problem updating even them if sufficient notice is given,
proper documentation provided, and if appropriate portions of the system
release identifiers are changed in meaningful ways.

Note that iff NetBSD were to offer support of a pulished standard for
driver and LKM interfaces then all of these issues w.r.t. 3rd-party
drivers and LKMs would not exist in the first place.  I.e. please refer
this part of the discussion to the thread titled "Uniform Driver
Interface proposal".

The only time an interface "MUST NOT" be changed is when the changes
would make it not conform to any published Standard that it's documented
as conforming with.  Such APIs should only be deprecated, something
totally separate (eg. which has no namespace clash with the existing
standards conforming interface) should be offered to replace it, and
then finally it can be removed in the next major release

So, indeed what this boils down to is that yes NetBSD should work
towards finding better ways to expose kernel internal functionality so
that 3rd-party developers can not only use the source code for reference
but also rely on published interfaces.  In the mean time though kernel
internals should not be unduely frozen just in fear that some 3rd-party
developer might be forced to do extra work to track them.

(and I'm not saying there has been unnecessary freezing of kernel
internals either -- in fact the kernel is probably the one place where
NetBSD hasn't been so "anal" about affect 3rd-party developers!)

BTW, I speak as a 3rd-party developer here too!

> People who REALLY need kernel internals can always -I/sys if they want.
> This requires installing the kernel source tarball, but is that so
> unreasonable?

This is indeed another solution and one that's not entirely off the wall.

It may even help reinforce the fact that 3rd-party software using
unpublished interfaces is indeed on its own w.r.t. tracking changes in
the kernel internals.

It might make some system tools harder to build in some scenarios.

-- 
							Greg A. Woods

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