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

Ingo Molnar
2009-02-04T20:09:28Z

* Andrew Morton <akpm@linux-foundation.org> wrote:

> > > This is getting painful.
> >
> > 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! ;-)
> >
> > 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.
>
> I like this one. The mixing up of declare-something with use-something
> is often the source of our woes.

yes. I mapped this problem area once and this is how the include file
spaghetti gets generated in practice:

- type A gets declared
- type A gets _used_ in the same file in an inline method, BUT,

that usage also brings in instantiated use of type X1, X2 and X3.

if all types are declared like that everywhere, it can be seen (and it's a
mathematical certainty) that the only conflict-free way of doing this is to:

- initially add random #include lines to bring in type X1, X2 and X3.
Which brings in recursive dependencies from those X1 X2 and X3 files.

- when the stuff hits the fan then folks are in a big mess already and
only a deep restructuring could gets them out of it - which they rarely
do in an iterative environment. So they work it around iteratively:
instead of new nice inline methods [which we really prefer] they delay
all the 'usage' instantiation to .c file via the use of CPP macros
[which we hate because they hide bugs and cause bugs].

Repeat that process for 15 years, on a 10 MLOC kernel with 1 MLOC headers
spread out in 10,000+ header files and you can see how it builds up to a big
pile of goo.

In fact i'm surprised it's not worse than it is - a mitigating factor are
uninlining efforts which happen to have the side-effect of reducing the
spaghetti.

The only structural change that would solve this situation is a tool that
enforces that type definitions and methods related to a type should never
mix. We are far from being able to enforce anything like that.

Ingo