Re: Cleaning up kernel's headers for userspace
On Tue, Apr 25, 2006 at 02:12:35PM +0100, David Woodhouse wrote:
> 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.
Indeed, which is why we took the other approach to this problem since we
need things to compile to our users, not just package maintainers :)
> 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.
Yeah, right now everybody's doing their thing -- centralizing should help
solve the problem for everybody.
> 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.
Hm, I quite like the idea of the #warning. And for files that are
blatantly pure __KERNEL__ we can just do:
#ifndef _LINUX_HEADERS_ASM_ARCH_BLARF_H
#define _LINUX_HEADERS_ASM_ARCH_BLARF_H
#warning "<linux::asm-arch/blah.h>: this header is deprecated, fix yer shizzle!"
#endif
into the file after declaring it "pure __KERNEL__" some such. If you could
fix the build scripts to do this to any file which isn't explicitly stated
as "userspace-OK" that would be great. That way you get noise (and
hopefully users file bugs) and at the same time things "work" and don't
break apps that #include looney headers :)
> > 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.
This has been a problem in the past. The other problem has been fixing
glibc so it includes headers in a sane way in places (we also got negative
feedback there when we tried).
Either way, since there's now hopefully a centralized place and aim for this
cleanup project and once we get things usable the kernel devs should finally
get the hint once it hits distribution trees ... that and hopefully Andrew
will back us up :)
> 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.
Nod.
> 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.
What we really need is not random kernel devs but arch maintainers. So
anything that goes in asm-arch "works".
> 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.
Guess I need to start to learn to use git properly :)
> 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.
When I get some time I'll look into x86+ia64.
Thanks,
Tim
Reply to: