[Ksummit-2012-discuss] [ATTEND] Proposed discussion: Cleaning up the header file mess

David Howells dhowells at redhat.com
Thu Jun 21 20:24:22 UTC 2012


Dave Jones <davej at redhat.com> wrote:

>  >  (1) Split the Userspace API (UAPI) out of the kernel headers into its own
>  >      header directories.
>  ...
> I suspect there's no coincidence you listed this as a first step.
> Just untangling the kernel/user parts of some files seems like it would be
> a pretty big (welcome) cleanup.

There are two reasons for this being the first step:

 (1) It reduces the size of the kernel-only headers and obviates the need for
     __KERNEL__ conditionals in the remnant kernel-only headers.

 (2) Splitting up a kernel header file such as linux/sched.h might mandate the
     userspace stuff be moved too - but I don't want to have to add more
     userspace headers if I can avoid it.

>  >  (4) Split some headers into definitions containers and inline function
>  >      containers to clean up recursion problems.  The main culprit is very
>  >      likely to be linux/sched.h, I think.
> 
> likely closely followed by mm.h / fs.h

Yep.

>  >  (6) Replace the traditional anti-reinclusion guards on header files with
>  >      three-state anti-recursion guards that abort compilation if recursive
>  >      inclusion is encountered.
> 
> interesting, have a pointer to documentation on these ?

Not really, it's all in my head at the moment, but something like:

	#if !defined(__FOO_H)
	#define __FOO_H 1

	#include <bar.h>
	#include <zebra.h>
	...
	...

	#undef __FOO_H
	#define __FOO_H 2
	#elif __FOO_H == 1
	#error Recursive header file inclusion
	#endif

There's an argument against doing this - the C preprocessor knows about the
normal 2-state guards and optimises for them.

However, with precompiled headers, hopefully that won't be a problem.

>  > (8) Provide a make target that tests all the KAPI and UAPI headers by
>  >      simply passing them one at a time to the compiler and attempting to
>  >      compile them.
> 
> I think someone did this before (Arnd maybe?) ISTR there being a lot of
> damage.

Doesn't surprise me.

I've also been working on a pair of scripts, one that works out what header
files should be used to supply what definitions and build a database, and one
that recalculates the #includes needed by each file.

There is a lot of excess #includeage from cut'n'paste file creation.

> The hardest part (after doing all the work of course!) I suspect is the timing
> of the merge ? ie, how to get it in without screwing over everything pending ?
> Maybe just get a pre-agreement from Linus to do a big merge post -rc1/rc2 ?

Actually, the timing is relatively easy for step (1).  It takes a matter of
minutes, normally, to regenerate the entire patch series.  A few minutes to
build allyesconfig for x86_64 and then I can post it.  Doing it immediately
after -rc1 would seem to be best.

As long as the userspace parts of the headers don't change, it doesn't
necessarily even need regenerating.

It should be less of a problem than the asm/system.h split as all it does is
move some headers to a new location if entirely userspace (added in a -I) and
otherwise just split any header that is partially exported into two and make
the KAPI side #include the UAPI side.

There is the odd case where the placement of the #include is not trivial, but
I think I've got all of those covered.

And then there's a bunch of generated patches that need applying to the DRM
headers to change "..." into <...> sort of thing.  THey've been checked over
by Dave Airlie.

David


More information about the Ksummit-2012-discuss mailing list