On Wed, Apr 11, 2001 at 07:22:16PM -0400, der Mouse wrote:
> This still feels to me like the sort of patronizing elitism I sketched
> in my previous message on this thread, which I might summarize as
> "don't worry your pretty little head about the internals, we'll tell
> you everything you need to know".

This may be an orthogonal issue, but it would be really nice to have a 
well-defined and documented kernel API.  One that's a lot more stable
than what we have now.  One that's guaranteed to not have any
functionality removed except possibly at major # updates.  This could
allow research groups some confidence that they can make kernel
additions (modules/whatever) and have them continue to work as long
as they stay on 1.x or 2.x as long as they stick to the published API.

I realize that this is not what you were talking about, but it is
kind of related.

FWIW, I don't have a problem with keeping all these header files in
/sys (or whatever) instead of in /usr/include/* and /sys as long as
they do not have user-accessible features.  If a file just has kernel
constants, data structures, and prototypes, then it really belongs only
within the kernel's view (which includes LKMs).

Files which contain ioctl() stuff or other sorts of things that _are_
accessible by user-land should be installed in /usr/include/somewhere.

-allen

-- 
 Allen Briggs                     briggs@wasabisystems.com
 http://www.wasabisystems.com/    Quality NetBSD CDs, Sales, Support, Service
NetBSD dev. for _your_ Alpha, ARM, M68K, MIPS, PowerPC, SH3, Sparc, x86, etc...