[Ksummit-2012-discuss] [ATTEND] Proposed discussion: Cleaning up the header file mess
dhowells at redhat.com
Thu Jun 21 18:43:51 UTC 2012
[Trying this again as my first post didn't seem to make it]
> Please summarize what expertise you will bring to the meeting,
I have written and modified code in a lot of different areas of the kernel,
including two arches, a filesystem, a network protocol and some VFS code and
some security code. I have also been involved in maintaining the NOMMU memory
As of late I've also been trying to clean up the header file problems and I've
been working on signing and verifying the signatures on modules.
> and what you'd like to discuss.
There are a number of things I'd like to suggest for discussion. I'll post
them in separate messages.
Firstly, Header file cleanups. I've been working on cleaning up the header
files for a while, trying to eliminate circular dependencies. I have a number
of steps I'd like to go through:
(1) Split the Userspace API (UAPI) out of the kernel headers into its own
(2) Move stuff out of the Kernel API (KAPI) headers that can be contained in
individual directories as it is referenced by a single file or directory
(3) Make coherent what can be found in commmon arch headers. asm/system.h has
been done now, but there's probably other stuff.
(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.
(5) I'd like to split some headers (e.g. linux/security.h) to reduce the
conditional recompilation burden. linux/security.h could have, for
instance, struct security_operations split out into a header file private
to the stuff in the security/ directory as the wrappers of its function
pointers are now out of lined in security/security.c.
(6) Replace the traditional anti-reinclusion guards on header files with
three-state anti-recursion guards that abort compilation if recursive
inclusion is encountered.
(7) Provide a script to go through and rejig the #includes of each source file
to have just the ones that are actually required (a lot of cut'n'pasting
goes on, and there are quite a few unnecessary #includes out there).
(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.
(9) Use precompiled headers.
I've managed to disintegrate asm/system.h as part of step (3). I would've
preferred it to be a later in the merge window, but it didn't cause too many
horrible problems - mainly missing #include files as far as I know. Thanks to
Paul Gortmaker for cleaning up a lot of the mess missed by Linus as part of
his work destruct testing linux-next and other stuff.
I've had part of step (1) pulled also and I'm hoping that at some point Linus
will pull the rest of step (1). I have scripts that regenerate the whole lot
for me, so generally redoing the patch series isn't much of a problem.
Step (1) Needs to be pulled as a coherent unit because one of the preparatory
patches breaks header installation in all header dirs until all the
per-header-dir patches are pulled. If I could get some help with it, I might
be able to remove this problem and then push the remaining prep patches to
Linus and push the per-dir patches via arch maintainers or whoever.
I believe Al Viro has been doing some of what I wanted to do in step (2) and
moving fs-specific stuff into fs-specific directories.
What I'd like to find out is how best to go about getting what I have upstream
to make it easier to deal with knottier problems (linux/sched.h being foremost).
More information about the Ksummit-2012-discuss