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

[David Woodhouse <dwmw2@infradead.org>]

On Sat, 2006-04-22 at 16:20 +0200, Adrian Bunk wrote:
> > Thats bacause the kabi subdir is broken by design.
> > Any approach that does not take into account the existing userbase is
> > broken by design and should be avoided.
> > The only sensible solution is to move out the kernel internal headers
> > from include/* to somewhere else.
> > And then slowly but steady let include/linux and include/asm-* be the
> > KABI.
> >...

The 'make headers_export' stage also works just as well as the above,
and it gives us something more concrete to work on, where we can _see_
the bits which are needlessly exported and start to clean them up.

> What exactly is the problem with creating the userspace ABI in 
> include/kabi/ and letting distributions do an
>   cd /usr/include && ln -s kabi/* .
> ?
> 
> Or with creating the userspace ABI in include/kabi/ and letting 
> distributions install the subdirs of include/kabi/ directly under 
> /usr/include?

The problem is that Linus is unlikely to accept a trivial cleanup patch
which, for example, removes the contents of linux/auxvec.h and creates
kabi/auxvec.h. He'll argue, as he did last year, that it's moving stuff
around for the sake of it.

On the other hand, he _would_ be likely to accept patches which split
existing files into two _within_ the include/linux directory. And that's
the important part of the task; it doesn't _matter_ where the files are
put, because we can deal with that in the 'export' stage, and we can
trivially move them around later anyway once we do have a consensus.

We're doing it this way because we want to get on with the real work
without getting bogged down in a discussion with Linus about the
pointless details. Unfortunately we're getting bogged down in a
discussion about the pointless details anyway.

If you can get the trivial patches to move stuff into kabi/ merged,
that's _FINE_. Go wild. If you can't, then it's still useful to do the
same cleanups but keep all the resulting files in the same directories.

The 'headers_export' make target is still useful in the meantime,
because it produces the set of headers which we expect people to put
into /usr/include, and which we can do sanity checks on.

-- 
dwmw2