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 <[email protected]>
Patch attached as .bz2 due to it's size (160k uncompressed).
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
On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
Tim Schmielau <[email protected]> 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?
On Thu, 28 Dec 2006, Andrew Morton wrote:
> On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
> Tim Schmielau <[email protected]> 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
On Thu, 28 Dec 2006 12:46:44 -0800 Andrew Morton wrote:
> On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
> Tim Schmielau <[email protected]> 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
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 <[email protected]> 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".
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
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
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:
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
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
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:
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
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:
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
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
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
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
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
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
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
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 <[email protected]>
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
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!
____