[lkml]   [2010]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] remove implicit slab.h inclusion from percpu.h

* Tejun Heo <> 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 :-/ ).



 \ /
  Last update: 2010-03-16 08:51    [W:0.116 / U:2.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site