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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
