ia32-base: Remove cpio and ext3 defaults

Submitted by Richard Purdie on Nov. 21, 2013, 3:25 p.m.

Details

Message ID 1385047536.16887.137.camel@ted
State Accepted
Commit 42484d72ed52a1a6f9d3f5b4bf46a72fbfbc490e
Headers show

Commit Message

Richard Purdie Nov. 21, 2013, 3:25 p.m.
On real IA hardware, neither the ext3 or cpio images are particularly useful
or used. cpio is legacy from initramfs and that specific image now overrides
FSTYPES accordingly. The size difference in filesystems makes ext3 as a file
format less useful, mainly being useful in the qemu case.

When needed users can still override the default FSTYPES so having
saner defaults makes sense. This improves build times and uses less
network bandwidth for builds and releases.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---

Patch hide | download patch | download mbox

diff --git a/meta/conf/machine/include/ia32-base.inc b/meta/conf/machine/include/ia32-base.inc
index 8a20bca..e15f927 100644
--- a/meta/conf/machine/include/ia32-base.inc
+++ b/meta/conf/machine/include/ia32-base.inc
@@ -10,7 +10,7 @@  MACHINE_FEATURES += "screen keyboard pci usbhost ext2 ext3 x86 \
 
 MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
 
-IMAGE_FSTYPES += "ext3 cpio.gz live"
+IMAGE_FSTYPES += "live"
 
 KERNEL_IMAGETYPE ?= "bzImage"
 

Comments

Darren Hart Nov. 21, 2013, 4:11 p.m.
On Thu, 2013-11-21 at 15:25 +0000, Richard Purdie wrote:
> On real IA hardware, neither the ext3 or cpio images are particularly useful
> or used. cpio is legacy from initramfs and that specific image now overrides
> FSTYPES accordingly. The size difference in filesystems makes ext3 as a file
> format less useful, mainly being useful in the qemu case.
> 
> When needed users can still override the default FSTYPES so having
> saner defaults makes sense. This improves build times and uses less
> network bandwidth for builds and releases.
> 
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

I'm fine with this, although it raises the question if we ought to be
doing anything more than tar rootfs in include files like this. there
are ia32 machines where a live image is not useful (although rare). Most
x86 BSPs would add live - but then again, most x86 BSPs will be starting
to consolidate on the genericx86 BSPs anyway....

But, this is a clear improvement as is.

Acked-by: Darren Hart <dvhart@linux.intel.com>

> ---
> diff --git a/meta/conf/machine/include/ia32-base.inc b/meta/conf/machine/include/ia32-base.inc
> index 8a20bca..e15f927 100644
> --- a/meta/conf/machine/include/ia32-base.inc
> +++ b/meta/conf/machine/include/ia32-base.inc
> @@ -10,7 +10,7 @@ MACHINE_FEATURES += "screen keyboard pci usbhost ext2 ext3 x86 \
>  
>  MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
>  
> -IMAGE_FSTYPES += "ext3 cpio.gz live"
> +IMAGE_FSTYPES += "live"
>  
>  KERNEL_IMAGETYPE ?= "bzImage"
>  
> 
>
Behrens, Holger Nov. 22, 2013, 10:49 a.m.
> On Thu, 2013-11-21 at 15:25 +0000, Richard Purdie wrote:
> > On real IA hardware, neither the ext3 or cpio images are particularly useful
> > or used. cpio is legacy from initramfs and that specific image now overrides
> > FSTYPES accordingly. The size difference in filesystems makes ext3 as a file
> > format less useful, mainly being useful in the qemu case.
> >
> > When needed users can still override the default FSTYPES so having
> > saner defaults makes sense. This improves build times and uses less
> > network bandwidth for builds and releases.
> >
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> 
> I'm fine with this, although it raises the question if we ought to be
> doing anything more than tar rootfs in include files like this. there
> are ia32 machines where a live image is not useful (although rare). Most
> x86 BSPs would add live - but then again, most x86 BSPs will be starting
> to consolidate on the genericx86 BSPs anyway....

live image does not build in case of INCOMPATIBE_LICENSE = GPLv3

Holger

> But, this is a clear improvement as is.
> 
> Acked-by: Darren Hart <dvhart@linux.intel.com>
> 
> > ---
> > diff --git a/meta/conf/machine/include/ia32-base.inc
> b/meta/conf/machine/include/ia32-base.inc
> > index 8a20bca..e15f927 100644
> > --- a/meta/conf/machine/include/ia32-base.inc
> > +++ b/meta/conf/machine/include/ia32-base.inc
> > @@ -10,7 +10,7 @@ MACHINE_FEATURES += "screen keyboard pci usbhost
> ext2 ext3 x86 \
> >
> >  MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> >
> > -IMAGE_FSTYPES += "ext3 cpio.gz live"
> > +IMAGE_FSTYPES += "live"
> >
> >  KERNEL_IMAGETYPE ?= "bzImage"
> >
> >
> >
> 
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Robert P. J. Day Nov. 22, 2013, 10:51 a.m.
On Fri, 22 Nov 2013, Behrens, Holger wrote:

> > On Thu, 2013-11-21 at 15:25 +0000, Richard Purdie wrote:
> > > On real IA hardware, neither the ext3 or cpio images are particularly useful
> > > or used. cpio is legacy from initramfs and that specific image now overrides
> > > FSTYPES accordingly. The size difference in filesystems makes ext3 as a file
> > > format less useful, mainly being useful in the qemu case.
> > >
> > > When needed users can still override the default FSTYPES so having
> > > saner defaults makes sense. This improves build times and uses less
> > > network bandwidth for builds and releases.
> > >
> > > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >
> > I'm fine with this, although it raises the question if we ought to be
> > doing anything more than tar rootfs in include files like this. there
> > are ia32 machines where a live image is not useful (although rare). Most
> > x86 BSPs would add live - but then again, most x86 BSPs will be starting
> > to consolidate on the genericx86 BSPs anyway....
>
> live image does not build in case of INCOMPATIBE_LICENSE = GPLv3
                                                ^^^?
  is that just a mail list typo or a copy and paste error?

rday