Messages in this thread | | | Date | Tue, 03 Feb 2009 14:37:51 -0800 | From | Jeremy Fitzhardinge <> | Subject | Re: mmotm 2009-02-02-17-12 uploaded (x86/nopmd etc.) |
| |
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 ;)
> 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.
J
| |