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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
