Re: Cleaning up kernel's headers for userspace
On Tue, 2006-04-25 at 10:25 +0200, Thorsten Kukuk wrote:
> 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.
Arjan did a certain amount of this when he owned the glibc-kernheaders
package in Fedora. We did trip up a few broken packages; notably those
including <asm/atomic.h> -- which wasn't even atomic in general on i386.
It shouldn't be that painful now.
We used to occasionally receive complaints that this was Fedora-specific
'breakage', and upstream maintainers were sometimes reluctant to fix
their abuse of header files.
That's another reason why it would be good to have this done _upstream_,
so that users can rely on the set of available headers being
_consistent_ between distributions.
If this is really a concern, then we can _start_ by shipping the
commonly-abused files with #warning in them, and phase them out over
time. I don't think that's either necessary or helpful though -- I'd
rather just drop them immediately. As I said in a previous mail though,
I'm _more_ interested in getting a consensus and moving forward and
getting this upstream than I am in the details of which headers we
actually include for now, so I'll capitulate on this if I have to.
> 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.
I think we will have to take the initiative to do the initial cleanup --
and I'm happy to coordinate that effort by providing access to a shared
git tree for collecting such patches. I agree that it's not realistic to
expect kernel developers in general to do that first step.
But I don't anticipate much negative feedback at this point. There is a
broad consensus among kernel developers that this _needs_ to be done,
even if none of us really relish the thought of doing it ourselves.
And after that initial cleanup, I _do_ expect random kernel developers
in general to care -- and the 'make headers_check' target can become a
useful tool to keep them in line. I'd expect to see patches getting
rejected if they cause regressions in userspace headers.
So where do we go from here? I've split the actual 'headers_install' and
'headers_check' stuff into a clean git tree in shared space at
git://git.infradead.org/hdrinstall-2.6.git and I'm currently
transferring the actual header cleanups I've already done into another
git tree at git://git.infradead.org/hdrcleanup-2.6.git -- using separate
trees just so that the actual cleanups can go upstream independently of
the export mechanism if necessary.
Hopefully, Andrew will be happy to pull both of these into his -mm tree.
They're also browsable in gitweb at http://git.infradead.org/
If you want an account with write access to these trees, send me a
public SSH key. In particular, I'd like people who care about
architectures other than PowerPC to look over the choice of files to be
exported, in asm-*/Kbuild.
--
dwmw2
Reply to: