Re: [PATCH] 'make headers_install' kbuild target.

[David Woodhouse <dwmw2@infradead.org>]

On Sat, 2006-04-22 at 15:20 +0200, Adrian Bunk wrote:
> Why can't the splitting happen incrementally?

It can, and has already started that way. There's no reason why the
'make headers_export' mechanism can't work with that -- it already does,
because it exports the include/mtd directory and nothing from
include/linux/mtd -- as I said, ideally the mechanism ends up being just
'cp -a' on certain directories. And then it can be abolished. We've got
a long way to go before we get there, though.

> Assume you have a header include/linux/foo.h:
> - Add an #include <kabi/linux/foo.h> at the top.
> - Move the part of the contents that is part of the userspace ABI to 
>   include/kabi/linux/foo.h.

Absolutely. That's what I've done with MTD headers already, although the
directory names are different. The directory names don't _matter_
either, because important part was that the files themselves are cleaned
up.

Linus isn't keen on splitting it into a new directory, and I don't want
to start off by demanding that. As I said, the important part of the
above is the bit where one of us goes to the file with an editor and
identifies the public parts vs. the private parts, then splits them up
-- possibly with #ifdef __KERNEL__, but _preferably_ into separate
files. And it doesn't _matter_ which directories we put those files
into, for now. I don't want to talk about it _yet_ because it's just
taking attention away from the real problem.

The more we screw around with such minutiae, the less likely we are to
get traction with Linus -- despite the fact that almost everyone who's
expressed an opinion is _agreeing_ with you about where we want to end
up.

We need to keep it simple and unintrusive to start with. Concentrate on
the _contents_ and then we can deal with the less important details
later.

-- 
dwmw2