Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[BAIN <bainonline@gmail.com>]

On Wed, 01 Dec 2004 01:06:17 +0000, David Woodhouse <dwmw2@infradead.org> wrote:
> On Tue, 2004-11-30 at 16:57 -0800, Linus Torvalds wrote:
> > This isn't even a "fix". It's a cleanup. It goes under the same rules
> > a spelling fix does.
> 
> So you don't see a long-term technical benefit in cleaning up the
> API/ABI we export to userspace so that userspace stops depending on
> stuff which just isn't supposed to be there? It's all just cosmetic
> masturbation as far as you're concerned? There's no point in trying to
> get to the point where we don't need to separately maintain a
> glibc-kernheaders package because it can be taken directly from the
> kernel?

There obviously _is_ a technical benefit. And to put out second usual
argument used to reject patches, this benefit is desirable/matters to
more than single digit number of users.

But lets face it, the changes you guies are discussing in this long
thread are _massive_. May be not so much theorotical mass. In theory
this is just a trivial movement of text from file to file with new
rules enforced on adding new text.
But this does boil down to a great number of user interfaces being
touched. And as far as the linux engineering practices go, this is
_huge_.

The costs are high, each header file change is going to affect
everything, the regression testing is going to be pain if we actually
go do the modifications suggested by this thread.

And lets face it, with a retard[1] chosen as our leader , _mistakes
will happen_. Things will _break_ and any decision taken will more
often be a false one.

But we already know a better way to do things. After all thats how we
have taken linux to the place where it is today. We can just start
making the changes. In small steps. See if anyone is really bothered
by the change. See if enough people give you feedback so that you are
bothered to propagate the change to newer level.

I would much rather like to see the glibc-kernelheaders shrunk by few
bytes every 3-4 months or so. And yes this actually has a chance that
it may never happen.

The whole "put forward an idea get a consensus" and then "try to
engineer it" works well for theory. But not in practise. In the end,
only the good things prevail not because they were created good, but
more because bad things can't servive. Leave the whole idea of "putting
a research together and try to do the ultimate right" for the FreeBSD
team.

And don't try to do the ultimate right without any reasearch, thats
microsoft's domain.

In summary, splitting the headers could be a good idea. But to have
any acceptance you need to prove it by practical examples. And when
you do new things, be prepared to accept that they might fail in
practise.

BAIN

[1]see: 
http://marc.free.net.ph/message/20041109.161141.2f4e1246.html