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

* Tejun Heo <tj@kernel.org> wrote:

> Hello,
>
> On 03/16/2010 03:54 PM, Tejun Heo wrote:
>
> > 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.
>
> Hmmm... here are some interesting numbers. Not completely exact but should
> give the general ballpark idea.
>
> all .c files : 13999
> .c files which use any of slab interface : 5603
> .c files which include slab.h : 2519
> .c files which include slab.h but don't use it : 577
> .c files which use slab but don't include it : 3661
>
> .c files with k[mzc]alloc/k[z]free usage : 5291
> .c files with other slab interface usage : 356
>
> C files which use k[mzc]alloc/k[z]free covers ~38% of all c files. One
> possibility is to separate out those into kmalloc.h and make it available
> universally via kernel.h.

Well, that's the main question: do we want all-in-one big headers like
kernel.h (and sched.h / mm.h) or not?

If we want to avoid combo .h files then we inevitably want to go for
finegrained, per subsystem data type and API definitions - i.e. explicit
slab.h inclusion in the .c file.

I'm leaning towards that solution of avoiding combo .h files - even if in the
slab.h case the concept causes us to touch quite a few .c files.

As long as it's expected to cause no shock we can do it in one big atomic
risk-free commit: which just adds the #include slab.h's to the .c files,
nothing else.

Look at the advantages:

- (slightly) sped up kbuild

- it would be immediately obvious in the future which .c file makes use of
SLAB facilities. We wouldnt have to guess or go to object file analysis to
figure out any 'true' usage.

- [ it would be trivial in the future to actually _remove_ stale #include
files. When there's no indirect inclusion of facilities then the lack of
usage can be decided based on API usage patterns in the .c files. ]

It's a much cleaner end result IMHO (which also happens to be faster to build)
- and slab.h is definitely the worst-case, so we should not wimp out just due
to that difficulty.

Thanks,

Ingo


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