Re: Simple header cleanups

[David Woodhouse <dwmw2@infradead.org>]

On Thu, 2006-04-27 at 15:00 -0700, Linus Torvalds wrote:
> This is one reason why we shouldn't even _plan_ on having header files 
> that can just be _directly_ used by the C libraries etc, even if it's just 
> a "small" kernel ABI header.
> 
> Selling it as that kind of idea will inevitably mean that we then get 
> blamed for not knowing magic rule #579 for SuS v2.1.6 subsection 8(a).
> 
> And if we say "you can use these headers unmodified", that _is_ what we're 
> going to get blamed for. I'm so _not_ interested in having to care or 
> worry. 

OK... I wasn't going to go here, because I don't want a potentially
contentious discussion to get in the way of the other cleanups which
I've been doing. We made that mistake at least year's Kernel Summit, and
we've made no progress since then despite having an almost unanimous
consensus on where we need to go.

But since Adrian's drawn you onto the topic, and since you've given me
an insight into what your objection is, I'll respond...

I don't think anyone imagines that a potential 'kabi' directory would be
used to specify anything like a _library_ interface, or that random
userspace programs would use stuff like 'struct stat' directly from it.
That would be like going back to the dark old days of libc5, and makes
me shudder as much as it does you.

Glibc has all that crap to define the interface between it and _its_
users. Its version of stuff like 'struct stat' may indeed vary according
to __USE_FILEOFFSET64 and the random standard of the day. We certainly
don't want to get involved with that kind of mess, I agree.

Our headers describe only _our_ interface to userspace, which often
bears no relation to glibc's interface to its users. We don't need to
care about our headers being usable in general by userspace
applications; only that they're useful for glibc. (With the exception of
stuff which defines ioctls, sockopts, etc.; obviously those are used by
system libraries and utilities rather than just glibc, but still -- it's
not just "random cross-platform POSIX userspace".)

Nobody _wants_ the hellish things you seem concerned about. All we want
to do is _think_ a little bit about avoiding gratuitous namespace
pollution in the headers -- for example, we should use only types like
__u32 instead of uint32_t and u32, we should refrain from exposing
private helper inlines, etc.

That's precisely what my cleanups have been fixing. It's not about
conforming to POSIX and other random standards so that our headers are
'clean' for direct inclusion as part of standard headers. This is _our_
interface, and our definition of it. It's just a case of being a little
bit disciplined about it rather than polluting it with internal crap.

Distinct from the cleanups, my existing 'make headers_install' takes the
limited set of headers which actually contain user-visible stuff, and
runs them through unifdef to get a consistent set of headers which all
distributions can use. The cleanups are just what was necessary to get
the resulting exported headers to the point where I can build glibc
against them on ppc, ppc64, i386, x86_64, s390, s390x and ia64. That's a
massive step forward, and it's all I really want to concentrate on right
now rather than talking about any potential 'next step'. What I'm doing
now stands on its own and is necessary.

However, there does seem to be a consensus that ifdefs are best avoided,
and that we should avoid them by splitting private stuff into one file,
public stuff into another, then including the latter from the former. I
haven't done that in the hdrcleanup-2.6.git tree; I've mostly just moved
stuff inside _existing_ '#ifdef __KERNEL__' guards within the same file.
But I _have_ done it in the past for include/linux/mtd/ (and put the
user-visible bits into linux/mtd/) and it's _much_ nicer that way.

_If_ we do that kind of thing, then it also makes some sense for the
user-visible files to be in one directory, and the private files to be
in another directory. That's just good practice.

That's all Adrian and others are talking about when they talk of a 'kabi
directory', I believe -- not your dystopian vision of trying to make our
headers conform to random standards-du-jour, but just treating them the
the same as we try to do in the actual C files through out the kernel --
avoiding ifdefs by splitting stuff into separate files, and grouping
those files into appropriate directories.

I think they're right, but I'm not arguing that point right now because
it's secondary to my task at hand, which is identifying the private vs.
public stuff in the first place and reducing the pollution so that our
headers are actually usable to build glibc again. In particular, I don't
want that discussion to get in the way of what I'm doing right now.

-- 
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/