[Ksummit-2012-discuss] [ATTEND] Proposed discussion: Cleaning up the header file mess
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
> > (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:
#define __FOO_H 1
#define __FOO_H 2
#elif __FOO_H == 1
#error Recursive header file inclusion
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
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.
More information about the Ksummit-2012-discuss