Re: mmotm 2009-02-02-17-12 uploaded (x86/nopmd etc.)

[Ingo Molnar <mingo@elte.hu>]

* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Ingo Molnar wrote:
>> the include file spaghetti is ... interesting there, and it's historic.
>>
>> I could blame it on highmem, PAE or paravirt - but i'll only blame it 
>> on paravirt for now because those developers are still around! ;-)
>>   
>
> Hey, don't forget unification, if we're pointing fingers ;)

Unification only moved stupidly separate crap closer to each other, making 
them all stink much more intensely. I consider that a feature! :)

>> Jeremy, any ideas how to reduce the historic dependency mess in that 
>> area? I think we should go on three routes at once:
>>
>>  - agressive splitup and separation of type definitions from method
>>    declaration (+ inline definitions). The spinlock_types.h / 
>> spinlock.h    splitup was really nice in solving such dependency 
>> problems.
>>   
>
> That already exists to some extent, though I don't think it's being used 
> to maximum advantage (pgtable-[23]level.h vs pgtable-[23]level-defs.h).  
> For consistency we'd have pgtable-4level(-defs).h headers too, and 
> top-level pgtable.h/pgtable-defs.h headers.  But its not clear to me that 
> would even be enough...

>>  - uninlining of methods: instead of macro-ing them - wherever 
>> possible.    It's really hard to mess up type + externs headers - while 
>> headers with    inlines and macros mixed in get painful quickly.
>>   
>
> Yes.  I went through a period of fairly aggressive inline->macro  
> conversion, and in many cases the remaining macros are there to #include  
> hell.
>
>>  - removal of spurious pile of dozens of #include lines in header files.
>
> Yeah, it would be useful to make sure that each header only #includes  
> the bare minimum headers to satisfy its own definitions - but of course  
> that's going to provoke a long series of #include whack-a-mole patches.

If you worry about the fallout, that's not a problem really. I'd expect most 
of the fixlets to go into .c files that used insufficient list of includes 
and relied on some previously existing spaghetti side-effect.

I even volunteer to whack them all myself, if you provide a large series of 
base patches that:

 1) happen to build and boot on any one of your favorite configs

 2) produce a squeaky clean .h file layout and dependency structure.

Doing a ping-pong with you of breakage+fixlet cycles wont scale too well, 
even with the very fast -tip turnaround. We could easily end up having to do 
dozens of followup fixes.

But it should be _really_ radical and the end result should be _really_ 
clean, to make the effort _really_ worth it :-)

	Ingo