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

David Howells 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
management code.

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
     header directories.

 (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
     of files.

 (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).

David


More information about the Ksummit-2012-discuss mailing list