Subject: Re: Kernel include files proposal
To: Greywolf <greywolf@starwolf.com>
From: Todd Whitesel <toddpw@best.com>
List: tech-kern
Date: 04/12/2001 01:08:51
> 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.

No hierarchy is being shuffled.

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.

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?

Todd Whitesel
toddpw @ best.com