Messages in this thread | | | Subject | Re: Simple header cleanups | From | David Woodhouse <> | Date | Fri, 28 Apr 2006 00:11:01 +0100 |
| |
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/
| |