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

[Adrian Bunk <bunk@stusta.de>]

On Sat, Apr 22, 2006 at 03:17:20AM +0100, David Woodhouse wrote:
>...
> Implementation details aside, the point is that we can now work on
> refining the choice of headers to be exported, and more importantly we
> can start fixing the _contents_ of those headers so that nothing which
> should be private is exported in them outside #ifdef __KERNEL__.
> 
> I've chosen headers in the generic directories and in asm-powerpc; the
> other asm directories could do with a proper selection being made; the
> rest of the current list is just inherited from Fedora's
> glibc-kernheaders package for now.
> 
> For a start, the headers I've marked for export are sometimes including
> headers which _weren't_ so marked, and hence which don't exist in our
> exported set of headers. I've started to move those inclusions into
> #ifdef __KERNEL__ where appropriate, but there's more of that to do
> before we can even use these for building anything and actually start to
> test them in earnest.
> 
> Adrian, I'm hoping we can persuade you to help us audit the resulting
> contents of usr/include/* and apply your usual treatment to the headers
> until it looks sane. That assistance would be very much appreciated.

My thirst thought is:
Is this really the best approach, or could this be done better?

I'm currently more a fan of a separate kabi/ subdir with headers used by 
both headers under linux/ and userspace.

Why?

Unless I'm misunderstanding this, your changes are giving a result 
identical result to simply using the current kernel headers (stripping 
the #ifdef __KERNEL__ stuff doesn't change anything).

If we want to define an ABI and do it right, the resulting ABI headers
should be write-only, and should even continue to contain the ABI for
code already removed from the kernel.

It should be possible to do this incrementically:
- without breaking the kernel at any time
- with no userspace breakages when switching to the ABI headers for 
  userspace (there might be corner cases, and if e.g. the asm-i386/atomic.h
  abuse by MySQL breaks that's not a loss)

This might take a bit longer, but as a result we have:
- an ABI where diffstat is able to tell us if someone has touched the ABI
  (can git trigger electric shocks for everyone trying to commit or pull 
   changes to the kabi/ subdir?  ;-)  )
- as a side effect, some cleanup of the current kernel headers

Unless someone can tell me a reason why this wouldn't work (except for 
being a bit more work than your approach), this is the approach I have 
in mind for working on.

> dwmw2

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
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/