[PATCH] remove 556 unneeded #includes of sched.h

[PATCH] remove 556 unneeded #includes of sched.h

[Tim Schmielau]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1009 bytes --]

After Al Viro (finally) succeeded in removing the sched.h #include in 
module.h recently, it makes sense again to remove other superfluous 
sched.h includes.
To ease the pain, this time I did not fiddle with any header files and 
only removed #includes from .c-files, which tend to cause less trouble. 
Also I left alone anything else that looked like any trouble, like hunks 
that didn't apply cleanly against both mainline and -mm trees. You see, 
I'd really like to get the patch through this time.

Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on
alpha, arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, 
defconfig, allmodconfig, and allyesconfig as well as a few randconfigs on 
x86_64. I also checked that no new warnings were introduced by the patch 
(actually, some warnings are removed that were emitted by unnecessarily 
included header files).

Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de>

Patch attached as .bz2 due to it's size (160k uncompressed).

[-- Attachment #2: Type: APPLICATION/X-BZIP2, Size: 12433 bytes --]

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Tim Schmielau]

After fiddling with this patch for so long, I forgot to mention an 
important thing:
This time the patch only includes things that need no fixups at all (most 
of these already went in last time).

So all hunks are independent, and you can just drop anything that does not 
apply or causes any other trouble. 

Thanks,
Tim

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Andrew Morton]

On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
Tim Schmielau <tim@physik3.uni-rostock.de> wrote:

> After Al Viro (finally) succeeded in removing the sched.h #include in 
> module.h recently, it makes sense again to remove other superfluous 
> sched.h includes.

Why are they "superfluous"?  Because those compilation
units pick up sched.h indirectly, via other includes?

If so, is that a thing we want to do?

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Randy Dunlap]

On Thu, 28 Dec 2006 12:46:44 -0800 Andrew Morton wrote:

> On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
> Tim Schmielau <tim@physik3.uni-rostock.de> wrote:
> 
> > After Al Viro (finally) succeeded in removing the sched.h #include in 
> > module.h recently, it makes sense again to remove other superfluous 
> > sched.h includes.
> 
> Why are they "superfluous"?  Because those compilation
> units pick up sched.h indirectly, via other includes?

I'm half done with a patch to remove includes of smp_lock.h.
For the files that I have patched, I checked each source file
for all interfaces in smp_lock.h to verify that none of them
are used, so the #include is just waste.

> If so, is that a thing we want to do?

Nope.

---
~Randy

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Tim Schmielau]

On Thu, 28 Dec 2006, Randy Dunlap wrote:

> I'm half done with a patch to remove includes of smp_lock.h.
> For the files that I have patched, I checked each source file
> for all interfaces in smp_lock.h to verify that none of them
> are used, so the #include is just waste.

Yes, that's what I also did. And then I checked for all interfaces in all 
headers included indirectly through sched.h and not already included in 
the respective source file to see whether any of these includes are needed 
to keep the file compilable (although this time, amazingly few includes 
had to be added back - only 5 for all 556)

Maybe I should have taken a look at my original patch descripions from 
last year, I admit the current one isn't very illuminating.

Tim

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Tim Schmielau]

On Thu, 28 Dec 2006, Andrew Morton wrote:

> On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
> Tim Schmielau <tim@physik3.uni-rostock.de> wrote:
> 
> > After Al Viro (finally) succeeded in removing the sched.h #include in 
> > module.h recently, it makes sense again to remove other superfluous 
> > sched.h includes.
> 
> Why are they "superfluous"?  Because those compilation
> units pick up sched.h indirectly, via other includes?
> 
> If so, is that a thing we want to do?

No, there is nothing at all in these files that needs sched.h. I suppose 
the includes are left over from times when more unrelated macros lived in 
sched.h (fortunately much of that cruft got cleand up already).

Tim

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Al Viro]

On Thu, Dec 28, 2006 at 09:58:17PM +0100, Tim Schmielau wrote:
> On Thu, 28 Dec 2006, Andrew Morton wrote:
> 
> > On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
> > Tim Schmielau <tim@physik3.uni-rostock.de> wrote:
> > 
> > > After Al Viro (finally) succeeded in removing the sched.h #include in 
> > > module.h recently, it makes sense again to remove other superfluous 
> > > sched.h includes.
> > 
> > Why are they "superfluous"?  Because those compilation
> > units pick up sched.h indirectly, via other includes?
> > 
> > If so, is that a thing we want to do?
> 
> No, there is nothing at all in these files that needs sched.h. I suppose 
> the includes are left over from times when more unrelated macros lived in 
> sched.h (fortunately much of that cruft got cleand up already).

Uh-huh.  How much of build coverage have you got with it?  Note that
"doesn't use symbols defined in sched.h" != "can remove include of
sched.h", which, in turn, is not the same as "removing it doesn't
cause problems on a couple of configs I've tried on amd64".

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Tim Schmielau]

On Thu, 28 Dec 2006, Al Viro wrote:

> Uh-huh.  How much of build coverage have you got with it?

Well, as said in the patch description, I compiled alpha, arm, i386, ia64, 
mips, powerpc, and x86_64 with allnoconfig, defconfig, allmodconfig, and 
allyesconfig as well as a few randconfigs on x86_64. I also checked that 
no new warnings were introduced by the patch.

> Note that "doesn't use symbols defined in sched.h" != "can remove 
> include of sched.h", which, in turn, is not the same as "removing it 
> doesn't cause problems on a couple of configs I've tried on amd64".

Sure. But from my experience (I started posting these patches almost five 
years ago, inspired by a blog entry by davej) actually the only thing that 
prevents removing the sched.h include (other than using symbols defined 
there) is dereferencing current, which my scripts also check.

Tim

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Russell King]

On Thu, Dec 28, 2006 at 10:18:12PM +0100, Tim Schmielau wrote:
> On Thu, 28 Dec 2006, Al Viro wrote:
> 
> > Uh-huh.  How much of build coverage have you got with it?
> 
> Well, as said in the patch description, I compiled alpha, arm, i386, ia64, 
> mips, powerpc, and x86_64 with allnoconfig, defconfig, allmodconfig, and 
> allyesconfig as well as a few randconfigs on x86_64. I also checked that 
> no new warnings were introduced by the patch.

That would not have covered the following drivers in this patch on ARM
then:

acorn/*
nwflash
i2c-iop3xx
i2c-s3c2410
ether1
ether3
etherh
omap_cf
pxa2xx_lubbock
sa1100_badge4
sa1100_cerf
sa1100_h3600
sa1100_jornada720
sa1100_neponset
sa1100_shannon
sa1100_simpad
acornscsi
arxescsi
cumana_1
cumana_2
ecoscsi
eesox
fas216
oak
powertec
at91_udc
omap_udc
pxa2xx_udc
zaurus

To cover these, you need to build at least rpc_defconfig, lubbock_defconfig,
netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc...

The whole "all*config" idea on ARM is utterly useless - you can _not_
get build coverage that way.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Randy Dunlap]

On Thu, 28 Dec 2006 21:34:38 +0000 Russell King wrote:

> On Thu, Dec 28, 2006 at 10:18:12PM +0100, Tim Schmielau wrote:
> > On Thu, 28 Dec 2006, Al Viro wrote:
> > 
> > > Uh-huh.  How much of build coverage have you got with it?
> > 
> > Well, as said in the patch description, I compiled alpha, arm, i386, ia64, 
> > mips, powerpc, and x86_64 with allnoconfig, defconfig, allmodconfig, and 
> > allyesconfig as well as a few randconfigs on x86_64. I also checked that 
> > no new warnings were introduced by the patch.
> 
> That would not have covered the following drivers in this patch on ARM
> then:
> 
> acorn/*
> nwflash
> i2c-iop3xx
> i2c-s3c2410
> ether1
> ether3
> etherh
> omap_cf
> pxa2xx_lubbock
> sa1100_badge4
> sa1100_cerf
> sa1100_h3600
> sa1100_jornada720
> sa1100_neponset
> sa1100_shannon
> sa1100_simpad
> acornscsi
> arxescsi
> cumana_1
> cumana_2
> ecoscsi
> eesox
> fas216
> oak
> powertec
> at91_udc
> omap_udc
> pxa2xx_udc
> zaurus
> 
> To cover these, you need to build at least rpc_defconfig, lubbock_defconfig,
> netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc...
> 
> The whole "all*config" idea on ARM is utterly useless - you can _not_
> get build coverage that way.

Uh, can J. Random Developer submit patches to the ARM build system
for testing?

---
~Randy

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Russell King]

On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote:
> On Thu, 28 Dec 2006 21:34:38 +0000 Russell King wrote:
> > The whole "all*config" idea on ARM is utterly useless - you can _not_
> > get build coverage that way.
> 
> Uh, can J. Random Developer submit patches to the ARM build system
> for testing?

Given that it takes about 8 to 12 hours to do a build cycle, that's
not practical.  The only real solution is for us to accept that
breakage will occur (and be prepared to keep a steady stream of
fixes heading into Linus' tree - which has been ruled out by Linus)
or J. Random Developer has to build a set of affected ARM defconfigs
themselves.

Or alternatively the guy who's running kautobuild needs an amount of
rather powerful donated hardware to stubstantially increase it's
throughput.

Or cross-gcc needs to be optimised to compile faster.

I don't see any of the above happening, so...

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Tim Schmielau]

On Thu, 28 Dec 2006, Russell King wrote:

> Given that it takes about 8 to 12 hours to do a build cycle, that's

My build cycle takes about 2 hours for 4 configs, on a decent AMD64 
system (running completely in tmpfs). Am I doing something wrong or are 
you talking about native builds?

Tim

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Russell King]

On Thu, Dec 28, 2006 at 10:53:44PM +0100, Tim Schmielau wrote:
> On Thu, 28 Dec 2006, Russell King wrote:
> > Given that it takes about 8 to 12 hours to do a build cycle, that's
> 
> My build cycle takes about 2 hours for 4 configs, on a decent AMD64 
> system (running completely in tmpfs). Am I doing something wrong or are 
> you talking about native builds?

I'm talking about cross-builds...  I don't know the spec of the machine,
only that it's x86 based (I don't run it.)

The last report at the beginning of this month said: 11 1/2 hours per
git snapshot, which is apparantly for building a total of about 115
kernels covering all ARM defconfigs, MIPS, PPC, and i386.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Tim Schmielau]

On Thu, 28 Dec 2006, Russell King wrote:

> I'm talking about cross-builds...  I don't know the spec of the machine,
> only that it's x86 based (I don't run it.)
> 
> The last report at the beginning of this month said: 11 1/2 hours per
> git snapshot, which is apparantly for building a total of about 115
> kernels covering all ARM defconfigs, MIPS, PPC, and i386.

Ah, that sound reassuring: 115 kernels in 11.5 hours = 6 minutes per 
kernel.

I just started building all arm defconfigs, and assabet_defconfig took
about 7 minutes. So I don't seem to be that far off.

Thanks,
Tim

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Randy Dunlap]

On Thu, 28 Dec 2006 21:48:30 +0000 Russell King wrote:

> On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote:
> > On Thu, 28 Dec 2006 21:34:38 +0000 Russell King wrote:
> > > The whole "all*config" idea on ARM is utterly useless - you can _not_
> > > get build coverage that way.
> > 
> > Uh, can J. Random Developer submit patches to the ARM build system
> > for testing?
> 
> Given that it takes about 8 to 12 hours to do a build cycle, that's
> not practical.  The only real solution is for us to accept that
> breakage will occur (and be prepared to keep a steady stream of
> fixes heading into Linus' tree - which has been ruled out by Linus)
> or J. Random Developer has to build a set of affected ARM defconfigs
> themselves.

I guess I don't get it.  Isn't that what we just went thru
with the struct nightmare^W work_struct changes?
But these header file changes are much simpler and more obvious...


> Or alternatively the guy who's running kautobuild needs an amount of
> rather powerful donated hardware to stubstantially increase it's
> throughput.
> 
> Or cross-gcc needs to be optimised to compile faster.
> 
> I don't see any of the above happening, so...

---
~Randy

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Tim Schmielau]

On Thu, 28 Dec 2006, Randy Dunlap wrote:
> On Thu, 28 Dec 2006 21:48:30 +0000 Russell King wrote:
> > On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote:
> > > On Thu, 28 Dec 2006 21:34:38 +0000 Russell King wrote:
> > > > The whole "all*config" idea on ARM is utterly useless - you can _not_
> > > > get build coverage that way.
> > > 
> > > Uh, can J. Random Developer submit patches to the ARM build system
> > > for testing?
> > 
> > Given that it takes about 8 to 12 hours to do a build cycle, that's
> > not practical.  The only real solution is for us to accept that
> > breakage will occur (and be prepared to keep a steady stream of
> > fixes heading into Linus' tree - which has been ruled out by Linus)
> > or J. Random Developer has to build a set of affected ARM defconfigs
> > themselves.
> 
> I guess I don't get it.  Isn't that what we just went thru
> with the struct nightmare^W work_struct changes?
> But these header file changes are much simpler and more obvious...

Well, I think it's practical to build all arm configs yourself. I'll do 
that for my sched.h #include changes. It's been less that two hours since 
I started the builds on two cpus and I already got 35 out of 59 configs.

It's just that one has to be aware of it. Before Russell's post the 
situation on arm seemed so confusing to me that I thought I'd just 
compile allnoconfig, defconfig, allmodconfig and allyesconfig and let the 
arm people figure out the rest.

Tim

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Randy Dunlap]

On Fri, 29 Dec 2006 01:37:39 +0100 (CET) Tim Schmielau wrote:

> On Thu, 28 Dec 2006, Randy Dunlap wrote:
> > On Thu, 28 Dec 2006 21:48:30 +0000 Russell King wrote:
> > > On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote:
> > > > On Thu, 28 Dec 2006 21:34:38 +0000 Russell King wrote:
> > > > > The whole "all*config" idea on ARM is utterly useless - you can _not_
> > > > > get build coverage that way.
> > > > 
> > > > Uh, can J. Random Developer submit patches to the ARM build system
> > > > for testing?
> > > 
> > > Given that it takes about 8 to 12 hours to do a build cycle, that's
> > > not practical.  The only real solution is for us to accept that
> > > breakage will occur (and be prepared to keep a steady stream of
> > > fixes heading into Linus' tree - which has been ruled out by Linus)
> > > or J. Random Developer has to build a set of affected ARM defconfigs
> > > themselves.
> > 
> > I guess I don't get it.  Isn't that what we just went thru
> > with the struct nightmare^W work_struct changes?
> > But these header file changes are much simpler and more obvious...
> 
> Well, I think it's practical to build all arm configs yourself. I'll do 
> that for my sched.h #include changes. It's been less that two hours since 
> I started the builds on two cpus and I already got 35 out of 59 configs.

Yep, right, if I already had all of that cross-build stuff setup,
it wouldn't be a big deal.  But getting it all setup is a big deal
(to me).

> It's just that one has to be aware of it. Before Russell's post the 
> situation on arm seemed so confusing to me that I thought I'd just 
> compile allnoconfig, defconfig, allmodconfig and allyesconfig and let the 
> arm people figure out the rest.

---
~Randy

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Tim Schmielau]

On Thu, 28 Dec 2006, Randy Dunlap wrote:

> Yep, right, if I already had all of that cross-build stuff setup,
> it wouldn't be a big deal.  But getting it all setup is a big deal
> (to me).

Well, I didn't want to say that you specifically should do that. ;-)

OTOH, if you are interested, setting it up isn't nearly as difficult as 
it seems. http://kegel.com/crosstool/ almost makes it a no-brainer.
It's some years ago that I set up mine, but if you want I'll write up 
a mini-howto about my setup. Al Viro also deschribed his setup:
http://lkml.org/lkml/2004/10/28/17

(and if you are frightened by the braindamage of my sched-removal-tools:
no, crosscompiling is nowhere as complicated as that.)

Tim

Re: [PATCH] remove 556 unneeded #includes of sched.h

[Tim Schmielau]

On Thu, 28 Dec 2006, Russell King wrote:

> To cover these, you need to build at least rpc_defconfig, lubbock_defconfig,
> netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc...

OK, I'll try to do that.
Do I need to build all the configs in arch/arm/configs?

> The whole "all*config" idea on ARM is utterly useless - you can _not_
> get build coverage that way.

Or shall I exclude the arm specific drivers for now?

Tim

[updated PATCH] remove 555 unneeded #includes of sched.h

[Tim Schmielau]

On Thu, 28 Dec 2006, Tim Schmielau wrote:
> On Thu, 28 Dec 2006, Russell King wrote:
> 
> > To cover these, you need to build at least rpc_defconfig, lubbock_defconfig,
> > netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc...
> 
> OK, I'll try to do that.
> Do I need to build all the configs in arch/arm/configs?

OK, building 2.6.20-rc2-mm1 with all 59 configs from arch/arm/configs 
with and w/o the patch indeed found one mysterious #include that may not 
be removed. Thanks, Russell!

Andrew, please use the attached patch instead of the previous one, it also 
has a slightly better patch description.

Thanks,
Tim

Re: [updated PATCH] remove 555 unneeded #includes of sched.h

[Tim Schmielau]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 301 bytes --]

On Fri, 29 Dec 2006, Tim Schmielau wrote:

> Andrew, please use the attached patch instead of the previous one, it also 
> has a slightly better patch description.

This time I actually attached something. Sorry.
(In case anybody wonders: yes, I did get some sleep while the builds were 
running)

Tim

[-- Attachment #2: Type: APPLICATION/x-bzip2, Size: 12367 bytes --]

Re: [updated PATCH] remove 555 unneeded #includes of sched.h

[Russell King]

On Fri, Dec 29, 2006 at 11:23:58AM +0100, Tim Schmielau wrote:
> On Thu, 28 Dec 2006, Tim Schmielau wrote:
> > On Thu, 28 Dec 2006, Russell King wrote:
> > 
> > > To cover these, you need to build at least rpc_defconfig, lubbock_defconfig,
> > > netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc...
> > 
> > OK, I'll try to do that.
> > Do I need to build all the configs in arch/arm/configs?
> 
> OK, building 2.6.20-rc2-mm1 with all 59 configs from arch/arm/configs 
> with and w/o the patch indeed found one mysterious #include that may not 
> be removed. Thanks, Russell!

Great, thanks for doing that.

Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [updated PATCH] remove 555 unneeded #includes of sched.h

[Oleg Verych]

On 2006-12-29, Tim Schmielau wrote:
[]
> OK, building 2.6.20-rc2-mm1 with all 59 configs from arch/arm/configs 
> with and w/o the patch indeed found one mysterious #include that may not 
> be removed. Thanks, Russell!
>
> Andrew, please use the attached patch instead of the previous one, it also 
> has a slightly better patch description.

Great job!

About patch. To make it smaller, i think, you better use less
"unified context" lines `diff -u1'.

Nice done! 
____