Subject: Re: Kernel include files proposal
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Lennart Augustsson <lennart@mail.augustsson.net>
List: tech-kern
Date: 04/12/2001 02:50:32
der Mouse wrote:

> > When something shows up that doesn't compile, we'll either install
> > the needed header file, or change the program if it is misdesigned.
>
> Who is this "we" that is supposed to somehow magically hear about it
> when Joe Codeauthor happens to use something in a way not heretofore
> anticipated and thereby needs another include file?  And how will this
> communication be accomplished?  (Don't forget to include a description
> of how Joe is supposed to find out about his end of it, if any.)

I expect "we" will hear about like any other bug that NetBSD has, by
a bug report.  And for the desperate person it is trivial to fix; just copy
the file from the source code for the system to /usr/include.  (Whoever
suddenly needs another file must know pretty well what (s)he needs.)


> Or to put it in a less confrontational but wordier way....
>
> 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".

No that's not it at all.  It's trying to make things comprehensible.
I view /usr/include/{sys,dev,...} as part of the "API" that the kernel presents
to userland.  If this contains a lot of extra fluff that is not really needed
it makes it much harder to understand what that API actually is.
I've looked in /usr/include/dev myself several times and thought "Ugh, this is
really messy", until I realized that what I was looking at was actually
internals of some device driver.  Things that I will never encounter
from userland were exposed, and in the interest of understanding I'd
rather not see them.  It's just a matter of abstraction, and it's the single
most important concept in software design.  Without it we would be
lost in a swamp of irrelevant details.

Note that there is nothing elitistic about this.  I'm not trying to hide anything
or claim that some things are too complicated for poor Joe User.  I'm saying
that to understand the API look at /usr/include/sys, to understand the internals
look at /sys.  Sometime the API will change and the things in /usr/include/sys
will be modified, added, or deleted.



> I feel this would crippling NetBSD as a research OS.  Or has NetBSD
> decided it's no longer going to try to support such things, presumably
> except within its own little developer fraternity?  I sure hope not.
> (Though it's already taken some steps in that direction, so maybe so.)

What on earth are you talking about?  Noone is talking about removing
any files, they are still there, just look in the proper place.  You are as free
to use them as you have ever been.  It's just a matter of clean design.

    -- Lennart