Re: [RFC] remove implicit slab.h inclusion from percpu.h

[Ingo Molnar]

* Tejun Heo <tj@xxxxxxxxxx> wrote:

> > Also, why should we make this opt-in and expose a wide range of configs to 
> > build breakages? A more gradual approach would be to write a simple script 
> > that adds a slab.h include to all .c's that include percpu.h, directly or 
> > indirectly.
> >
> > You can map the pattern experimentally: the insertion pattern could be 
> > built from the x86 allmodconfig build you did [i.e. extend the pattern 
> > until you make it build on allmodconfig] - that would cover most cases in 
> > practice (not just allmodconfig) - and would cover most architectures as 
> > well.
> 
> I don't really get the 'experimental' part but if I count all the files 
> which ends up including percpu.h directly or indirectly on allmodconfig it 
> ends up including much more .c files than necessasry - 11203 to be exact, 
> ~20 times more than necessary.  Inclusions from .c files definitely are much 
> less troublesome so the situation would be better than now but we'll still 
> end up with a LOT of bogus inclusions without any good way to eventually 
> remove them.

That raises another problem we have: based on the sanitization of #include 
lines in a couple of files in the past, about 70-80% [+-10%] of all include 
lines are superfluous and duplicative.

So besides include file dependency incest, we have a random #include mess at 
the top of virtually every .c file in the kernel that has been around for more 
than a couple of years.

That too slows down the kernel build.

> Maybe a better way is to grab for slab API usages in .c files which don't 
> have slab.h inclusion.  If breaking the dependency is the way to go, I can 
> definitely write up some scripts and do test builds on some archs.  There 
> sure will be some fallouts but I think it won't be too bad.

Yeah, actual API usages would be quite good as an insertion pattern. I've done 
a good deal of such large-scale conversions in the past, and what worked (for 
me) best was along the lines of:

 - step 1: shoot for an all-tree scripted conversion (which tries to overshoot 
           the target, not under-shoot it)

 - step 2: some good build testing as there's always a few exceptions not 
           worth scripting

The solution you went for is good for an initial prototype, but i'd expect it 
to cause quite some build breakage that will be a shock to the system.

The shock can be avoided i think, with some more work (on your side :-/ ).

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/