Subject: Re: Kernel include files proposal
To: Todd Whitesel <toddpw@best.com>
From: Greywolf <greywolf@starwolf.com>
List: tech-kern
Date: 04/12/2001 22:48:22
Hi, Todd!

On Thu, 12 Apr 2001, Todd Whitesel wrote:

# > 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.
#
# I think you came in late.

(nah, I'm just up too late botching about too much little shot.)

No, I've been watching this, actually, and I just don't think the move is
worth the gain.

# No hierarchy is being shuffled.

Bad wording, probably, on my part.

# Previously there were large numbers of kernel-private headers installed into
# /usr/include. These headers still exist under /usr/src. The intent of the
# change is to stop installing many of these headers, on the grounds that
# userland programs cannot ever access the parts of the kernel that they
# describe.
#
# 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.
#
# Please do not argue that all of userland needs to see all of the kernel
# headers. 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.

Dammit, I'm split here; part of me is rebelling and saying, "butbutbutbut
you can't just rip it out like that -- that kinda makes more work for the
install makefiles (and the maintainers thereof)".

The other part agrees with you, so you've obviously got a valid point :-)

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

Probably not.  But hit me with a big clue-by-four, would you?  I don't
understand the need to really restrict the set.

Ah, well, as long as I'm not maintaining it, I shouldn't complain.
As you point out, if you really want to read the stuff, install the
kernel source tarball.

# Todd Whitesel
# toddpw @ best.com

				--*greywolf;
--
*BSD: We Suck Less