Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: Simple header cleanups | From | David Woodhouse <> | Date | Fri, 28 Apr 2006 01:55:59 +0100 |
| |
On Thu, 2006-04-27 at 17:01 -0700, Linus Torvalds wrote: > As long as people realize that any kabi headers would only ever be used by > system libraries _internally_ to build themselves (or strange system > tools, of course), then I'm happy. I just get the feeling that people > don't always realize that, and they really want to see it as some kind of > "/usr/include/bits" kind of thing.
Absolutely. There's no justification for kernel headers being treated like that -- and one of my goals is to _reduce_ the amount they get abused in that fashion. Certainly nobody wants to allow the abuse to increase.
And of _course_ there are people who don't fully grasp the situation. We've been entirely inconsistent about it with the "Never use kernel headers" mantra, when we _know_ it actually has to be done in certain special circumstances.
That's _why_ I want a 'make headers_install' which copies out (and unifdefs) a strict subset of headers which were chosen by hand -- it makes it very clear what is permitted, and what is not. Traditionally, distributions have been far too liberal about what they've exposed, and it's led to people doing insanely broken things like using <asm/atomic.h> even though it isn't even actually atomic on i386 in userspace. That needs to stop.
There is a small set of headers which we _need_ to export, for the benefit of glibc, gdb and some Linux-specific tools which use ioctls and sockopts. Nothing else should be exposed; random userspace apps shouldn't _want_ to include kernel headers.
The point of what I'm doing is to be strict about what we export, to _discourage_ the abuse of stuff which shouldn't really have been visible in the first place. And to be _consistent_ across Linux distributions about what is available and what is not. (With the vast majority being 'NOT', because that's just sane.)
That's what git://git.infradead.org/hdrinstall-2.6.git is about.
As a separate quality of implementation issue, those headers which we _do_ need to export should be exported in a form which is actually useful, and which doesn't require each distributor to maintain their own fork by hand or use evil sed tricks like this one the Gentoo maintainer showed me...
headers___fix() { # Voodoo to partially fix broken upstream headers. # Issues with this function should go to plasmaroo. sed -i \ -e "s/\([ "$'\t'"]\)\(u\|s\)\(8\|16\|32\|64\)\([ "$'\t'"]\)/\1__\2\3\4/g;" \ -e 's/ \(u\|s\)\(8\|16\|32\|64\)$/ __\1\2/g' \ -e 's/\([(, ]\)\(u\|s\)64\([, )]\)/\1__\264\3/g' \ -e "s/^\(u\|s\)\(8\|16\|32\|64\)\([ "$'\t'"]\)/__\1\2\3/g;" \ -e "s/ inline / __inline__ /g" \ "$@"
That's what git://git.infradead.org/hdrcleanup-2.6.git is about. It's just simple fixes.
What Adrian brings up is a _third_ issue, one which is fairly uncontentious in the context of C files: that ifdefs are generally bad and should be avoided. Instead of using ifdefs, it's nicer to split stuff into separate files. Also, files should be grouped together into directories as appropriate for their purpose.
In the specific case of kernel headers, the consensus seems to be that we should tend to avoid __KERNEL__ by making separate 'public' files for those bits which _have_ to be public -- we can include those public files from other, entirely-private, files. And there also seems to be agreement that those 'public' files should live in a directory together where we can immediately see when we're changing the ABI, etc. For want of a better name, people have referred to this as a 'kabi directory'.
I've been avoiding this third issue since it seems to cause you a lot of concern -- perhaps because we'd managed to miscommunicate the intent, and we shouldn't have said "public" when we do really mean it's only for Linux-specific libraries and tools, not 'public' for general applications. I've also been avoiding it because with my new 'make headers_install' it isn't _quite_ so much of an issue as it once was -- although I do still agree with the general consensus that it's probably a good idea anyway.
-- dwmw2
- 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/
| ![\](/images/icornerr.gif) |