Re: [ [git pull] headers_check fixes]

From: Vegard Nossum
Date: Tue Jan 27 2009 - 18:51:47 EST

On Wed, Jan 28, 2009 at 12:31 AM, Ingo Molnar <mingo@xxxxxxx> wrote:
> It would be much better if we exported _much_ less and reduced our
> cross-section to user-space. Also, the include/linux/Kbuild rules are all
> but transparent: it would also be nice if whatever we exported was be
> visible straight in the header itself, to make it obvious to people who
> modify/extend those files that those definitions are going to be exported
> to user-space.
> Some __user_export tag on structures perhaps? I have no good ideas here -
> #ifdefs are ugly and tags obscure the purity of the code.

Something that might or might not be doable in practice, but at least
it's a suggestion that I haven't seen elsewhere:

Create an include/user/ directory that contains a "mirror" of the
include/ directory _structure_, so that random exported header
include/linux/foo.h now has two parts -- include/linux/foo.h and

- include/user/linux/foo.h contains the definitions that are needed by
both kernel and userspace
- include/linux/foo.h contains the definitions that are needed only by
the kernel
- include/linux/foo.h can simply #include <user/linux/foo.h> and no
other change (to source files which _use_ this header) is necessary
- no dependency on a kernel header will exist in a "user" header --
that's how it is now, but this way is more explicit
- the whole include/user/ can be shipped verbatim to /usr/include (or
wherever it is needed)
- no #ifdef __KERNEL__ or #ifdef CONFIG_ stuff in the "user" headers;
no stripping or unifdefing is needed
- it's easier to see exactly what is being exported

Of course, obvious disadvantages are:

- less readable in the sense that what used to be in one file is now
spread across two
- the split itself would probably require a tremendous effort
- other things?

It's just an idea...


"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at