On Thu, 12 Apr 2001, Lennart Augustsson wrote:

# der Mouse wrote:
# > 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.

I thought that was what manual sections 2, 3, 4 and 9 were for.

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

RTM.  That's supposedly what documentation is all about.

Or do you maintain that someone should be able to install base, etc and
comp and magically be able to divine the interfaces between the kernel
and userland?

I somehow don't see that as acceptable.

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

I think I can see stuff that is guaranteed to be used only by the kernel
as avoidable for putting into /usr/include/ somewhere.

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

On a previous tangent:

As far as "data hiding", as a programmer, I've *hated* that concept.
"The programmer doesn't need to know what's being passed".  The fsck I
don't!  I'm writing code that uses it -- I want to know what it is!
"We don't want to tell the programmer what's being passed".  Fine.
Sun did that.  I found a better OS -- this one!

# 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 don't see this sudden change as being worth the effort to straighten it
out.

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

In this effort to champion "clean design" you're making more work for your-
selves in jostling the Makefiles referenced when you run "make includes"
from /usr/src.

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

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.

SPARC needs a working 24-bit graphics driver.  It will probably never get
one, because the number of people who a) have the guts and the mind to
attack the driver; b) who have the hardware and c) who have the time
is probably close to a non-overlapping region of those three attributes.

MP is coming along, but as has been pointed out, we don't have a gross
of programmers to toss at that problem.

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!

But I find the "cleanup" rather gratuitous in the face of other problems.

Sorry if I'm being an a) clueless b) raving c) dick about this, but every
mod I've seen us make is an effort to conform to some strange pressure
which I don't understand.  I thought we were based on technical excellence,
not the marketplace (which, last I looked, doesn't give a flying dynamically-
linked interface through a token ring who's got the technical edge!).

#     -- Lennart

				--*greywolf;
--
*BSD: The Last Bastion of the true UNIX Religion.