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

* Alexey Dobriyan <adobriyan@gmail.com> wrote:

> On Tue, Mar 16, 2010 at 8:17 AM, Ingo Molnar <mingo@elte.hu> wrote:
> > Also, why should we make this opt-in and expose a wide range of configs to
> > build breakages?
>
> Because we want to #include less, not the same amount.
>
> > 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.
>
> As a defensive measure, one can explicitly add slab.h to every file which
> uses kmalloc/kfree.
>
> But, who cares, since one still has to compile test regardless.

Firstly, generating #include slab.h lines in .c files based on actual API
usage is _good_, pretty much unconditionally so. See my previous mail for the
list of advantages. Even if it increases the number of #include lines
temporarily.

Secondly, the point in scripting is to intentionally over-shoot the target, as
compile testing (especially if it's only modconfig), will only cover so much
and _if we can_ we should avoid breakage.

That way the over-shooting will cover cases you are not able (or did not
happen to) build-test. It's much better to have temporarily more include lines
than have fewer and break the build. We'll need a #include line reduction
mechanism in any case as APIs frequently get unused and #include lines get
amassed in .c files.

Thirdly, as for build testing only, see for example a sched.h include file
cleanup _you_ did in the past, which, despite your build testing, broke quite
some code:

commit 86ae13b006e48959981248493efd3ff4b2828b3d
Author: Ingo Molnar <mingo@elte.hu>
Date: Mon Oct 12 16:22:46 2009 +0200

headers: Fix build after <linux/sched.h> removal

Commit d43c36dc6b357fa1806800f18aa30123c747a6d1 ("headers: remove
sched.h from interrupt.h") left some build errors in some configurations
due to drivers having depended on getting header files "accidentally".


Signed-off-by: Ingo Molnar <mingo@elte.hu>
[ Combined several one-liners from Ingo into one single patch - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

drivers/char/genrtc.c | 1 +
drivers/char/rtc.c | 1 +
drivers/char/sonypi.c | 1 +
drivers/net/wan/c101.c | 1 +
drivers/net/wan/n2.c | 1 +
drivers/net/wan/pci200syn.c | 1 +
drivers/pci/hotplug/cpqphp.h | 1 +
7 files changed, 7 insertions(+), 0 deletions(-)

I dont mind the occasional breakage, but avoidable bugs spread out in the tree
can be a real PITA to testers.

I remember it, that imperfect conversion kept me busy chasing trivial build
bugs for most of the day, because they would pop up with different config
dependencies so they had to be addressed separately. (so i created 7 separate
fixes as the day progressed - and that in a busy period of the cycle so i
certainly didnt have a day to waste voluntarily)

Note that that d43c36dc patch of yours wasnt in linux-next IIRC, so you didnt
even get basic build coverage. I have no problem with fixing more difficult
bugs or with fixing the occasional silly oversight (that's the _point_ of
developing the kernel after all), but i have a problem with reasonably
avoidable bugs.

Thanks,

Ingo


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