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

[Dave Jones]

On Thu, Jun 21, 2012 at 07:43:51PM +0100, David Howells wrote:

 > 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:

Kudos for even trying to do something about this hairball.

 >  (1) Split the Userspace API (UAPI) out of the kernel headers into its own
 >      header directories.

I'd really like to see this happen. I think it would fix a lot of problems
we've had historically with "oh, userspace shouldn't have been using that".
I wouldn't be surprised if there are still cases of that that will fall out of
such a reworking.

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.

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

sounds like something that could eventually be folded into checkpatch too maybe.
(or perhaps called from it)

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

 >  (9) Use precompiled headers.

Lofty goals!

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

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 ?

	Dave