qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RfC PATCH 0/3] edk2: add efi firmware builds
Date: Wed, 23 Nov 2016 14:54:33 +0000	[thread overview]
Message-ID: <20161123145433.GH6750@redhat.com> (raw)
In-Reply-To: <1479907484-4988-1-git-send-email-kraxel@redhat.com>

On Wed, Nov 23, 2016 at 02:24:41PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> This patch series adds a edk2 submodule in roms, also a build script
> and makefile rules to build ovmf and arm firmware.
> 
> The build script creates per-arch subdirs in pc-bios and places the
> firmware files there.  They are not exactly small:
> 
>    kraxel@nilsson ~/projects/qemu (work/edk2)# du -s -h pc-bios/edk2-*
>    2,8M    pc-bios/edk2-aarch64
>    2,8M    pc-bios/edk2-arm
>    2,1M    pc-bios/edk2-i386
>    2,1M    pc-bios/edk2-x86_64
> 
> So, the question is how we wanna go forward with this.  Adding the
> submodule and rules is a no-brainer I think.  But what about the
> binaries, which sum up to roughly 10M?  Ship them all?  Ship the
> 64bit archs only, given that efi never really took off on i386
> and arm?
> 
> Other comments?

Should we think about our policy for distributing & shipping ROMS
more generally ?  Most distros will actively strip out the ROMs that
we ship in the QEMU tar.gz releases, and rebuild them from pristine
source in order to ensure they're fully complying with licensing
requirements wrt "full & corresponding source".

So should we consider actually shipping 2 tar.gz files for QEMU
releases. One minimal qemu-x.y.z.tar.gz that only contains pristine
QEMU source with no pre-built artifacts, and a second qemu-full-x.y.z.tar.gz
that contains the QEMU source, plus an arbitrary number of pre-built
blobs.

Alternatively, instead of a qemu-full-x.y.z.tar.gz, we could just
have a qemu-roms-x.y.z.tar.gz bundle which only contained the ROMs,
which users would use in combination with the other releae.

Vendors would use the minimal release, while users who just want to
build their own QEMU with least effort would  use the full release
tar.gz

If we had some split like this, then I think we would not have to
really worry about the fact that the ROMs will get quite large
as the size would only impact people wanting to download the full
release.

In terms of GIT, we could likewise make the binary ROMS live in
a submodule, so we don't bloat the main GIT repo, but I don't
think that's so critical

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

  parent reply	other threads:[~2016-11-23 14:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-23 13:24 [Qemu-devel] [RfC PATCH 0/3] edk2: add efi firmware builds Gerd Hoffmann
2016-11-23 13:24 ` [Qemu-devel] [RfC PATCH 1/3] edk2: add submodule Gerd Hoffmann
2016-11-23 13:24 ` [Qemu-devel] [RfC PATCH 2/3] edk2: add build script and rules Gerd Hoffmann
2016-11-23 13:24 ` [Qemu-devel] [RfC PATCH 3/3] edk2: use EfiRom utility from edk2 submodule Gerd Hoffmann
2016-11-23 14:54 ` Daniel P. Berrange [this message]
2016-11-28 10:07   ` [Qemu-devel] [RfC PATCH 0/3] edk2: add efi firmware builds Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161123145433.GH6750@redhat.com \
    --to=berrange@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).