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 i
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 + Russell King wrote:
> > > On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote:
> > > > On Thu, 28 Dec 2006 21:34:38 + Russell King wrote:
> >
On Thu, 28 Dec 2006, Randy Dunlap wrote:
> On Thu, 28 Dec 2006 21:48:30 + Russell King wrote:
> > On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote:
> > > On Thu, 28 Dec 2006 21:34:38 + Russell King wrote:
> > > > The whole "all*config" idea on ARM is utterly useless - you can _n
On Thu, 28 Dec 2006 21:48:30 + Russell King wrote:
> On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote:
> > On Thu, 28 Dec 2006 21:34:38 + Russell King wrote:
> > > The whole "all*config" idea on ARM is utterly useless - you can _not_
> > > get build coverage that way.
> >
> >
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 ab
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 do
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
-
To u
On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote:
> On Thu, 28 Dec 2006 21:34:38 + 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
>
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" ide
On Thu, 28 Dec 2006 21:34:38 + 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, ar
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, defcon
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
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
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 re
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
> > s
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 include
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 compilat
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
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 troubl
19 matches
Mail list logo
