[ On Wednesday, April 11, 2001 at 22:59:51 (-0700), Greywolf wrote: ]
> Subject: Re: Kernel include files proposal
>
> I think I can see stuff that is guaranteed to be used only by the kernel
> as avoidable for putting into /usr/include/ somewhere.

I should certainly hope so!

> What, though, of the poor soul who decides for whatever deranged reason
> to implement a protocol stack or a driver in userland?  (The versions
> of pppoe come to mind.)

What does this have to do with internal kernel structures and
defintions that will be totally unrelated to any user-land
implemantation?

> I understand that some people "want clean design".  I still fail to see
> what the true net gain for this move is.

Well, there's clean design and there's absolutely horrendously stupid
spaghetti design.

In an ideal world where /dev/kmem is outlawed for all but kernel
debuggers only the descriptions of items used in kernel/user interface,
be it a set of ioctl() commands, sysctl() commands, a specific system
call, or any data structure that might be passed either way to any such
interface, etc., should ever be included in /usr/include/sys.

However while there's still a libkvm *all* internal headers describing
*all* internal data structures and variables (and of course their
related constants, etc.) should be placed in /usr/include/sys for all to
see.

Where this all gets interesting of course is when an internal
implemenation shares its data definitions and other declarations with
public user-land interfaces.

I.e. at the current time about the only thing that doesn't belong in
view of userland are prototypes for kernel functions not callable
directly from userland.  However in the interests of keeping down just ht

> We're sitting here shuffling the hierarchy -- to me, this amounts to not
> much more than mental masturbation when there is SO much more that could
> stand to be done!  Now, I'm hardly one to talk, but I regrettably lack
> the requisite expertise to attack those problems.

You're probably 100% right there....  :-)

> I'm about to go off and see where the sparc installer is at this point --
> if it's not in line with what the i386 one does, I'm wont to fix it, since
> I have a deeply vested interest in a nicely working sparc installer!

It's not bad, but I've had problems with both this week.....  :-)

-- 
							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>