[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Cleaning up kernel's headers for userspace



On Mon, Apr 24, David Woodhouse wrote:

> > The other problem is the vastness of our architecture support - we
> > do from x86 to m68k and all those headers need to work -- hence
> > hand-picking really never was seen as the viable option as it means
> > a *lot* of work between upstream releases. Our current way you just
> > fix a few conflicts with the patches have when you move from say 2.6.16
> > to 2.6.17, and run test-cases to see if any new gremlins have
> > appeared.
> 
> The idea is that this all happens upstream; no such merges would be
> required. Once we've got it sorted out, the architecture maintainers are
> responsible for the output of 'make headers_install' on their
> architecture, and 'make headers_check' exists for automated checking of
> the results. If you have more checks which we should apply during the
> 'make headers_check' stage, that would be useful.

Personally I like the idea to install only the necessary kernel header
files without the #ifdef __KERNEL__ part very much. This would solve a
lot of problems I currently have, but it would also create a lot of 
headache for this people, who are using the then missing header files
excessive. And for the distributors, who have to fix this packages
initially.
I had already since a long time the idea to include only this header
files, which are needed or referenced by glibc itself, but I never had
the time to do so.

But I don't think it is realistic that kernel developers will start
fixing their header files for user inclusion. In most cases you will
get only negativ feedback if you send patches, which fixes header
files for userland inclusion.

  Thorsten

-- 
Thorsten Kukuk         http://www.suse.de/~kukuk/      kukuk@suse.de
SUSE LINUX Products GmbH       Maxfeldstr. 5       D-90409 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = 8C6B FD92 EE0F 42ED F91A  6A73 6D1A 7F05 2E59 24BB



Reply to: