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

[David Woodhouse <dwmw2@infradead.org>]

On Sat, 2006-04-22 at 16:28 +0200, Sam Ravnborg wrote:
> First off:
> There are many other users that poke direct in the kernel source also.
> 
> Secondly and more importantly:
> Introducing kabi/ you will have a half solution where several users will
> have to find their stuff in two places for a longer period.
> kabi/ does not allow you to do it incrementally - it requires you to
> move everything over from a start.

Not really, because we have a 'make headers_install' target which puts
everything together in one place, cleaned up, for userspace. It can
quite happily pick up files from both the existing directories and the
new kabi/ directory. 

If Adrian wants to move stuff into a kabi/ directory as part of the
cleanups, that's fine. I think it's pointless, and I think it reduces
his chances of actually getting his cleanups merged, but if that's the
only way he'll contribute his time, then so be it. It doesn't do any
harm, technically.

But really, this whole discussion is counterproductive, IMO. 

The post-processing step to export headers to userspace is fine for now.
It lets us get on with the real work of cleaning the headers up. We've
been blocked on the trivia for too long already, and we're going down
that path again.

Once we have the actual contents of the headers classified as public vs.
private, and we know what we've got, _THEN_ we will have a clearer idea
of how those public headers should be organised. And it's _trivial_ to
move stuff around once it's been split out. It just doesn't _matter_
where we put it, for now.

What I'd really like to do is go into KS with the headers already
cleaned up, using 'make headers_install'. Show Linus the results, have a
coherent plan for how it _should_ be laid out so that the 'make
headers_install' step becomes just a copy, as Adrian and everyone else
wants. And have him actually agree to it this time.

We can't do it the other ways round. We tried that. If that was the only
way we could get Adrian to help us, then that's unfortunate, because
_this_ is the only way I think Linus is going to take it.

The end result is fairly much the same either way, and the amount of
work is the same. 

-- 
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/