From: Patrick Ohly <patrick.ohly@intel.com>
To: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH v4 05/12] ovmf: deploy firmware in image directory
Date: Mon, 23 Jan 2017 08:45:51 +0100 [thread overview]
Message-ID: <1485157551.20333.14.camel@intel.com> (raw)
In-Reply-To: <1485156197.41148.8.camel@ranerica-desktop>
On Sun, 2017-01-22 at 23:23 -0800, Ricardo Neri wrote:
> On Fri, 2017-01-20 at 15:12 +0100, Patrick Ohly wrote:
> > The traditional usage of ovmf via the qemu bios parameter is no longer
> > supported
>
> I don't see dropping support for this option in this series.
>
> Is part of
> another series? I just checked the poky repo and I still the the option
> supported. Or do you mean that only the ovmf recipe will not support
> exporting bios.bin?
Yes, the latter.
> > and therefore it is not necessary to create a "bios.bin"
> > file in the target sysroot.
>
> Wouldn't this particular part of the patch break the existing runqemu.
> If this is the case, perhaps the last patch (or a patch towards the end
> of the series) can remove this functionality in both places.
Could be done, but personally I prefer to add something new before
taking away the old approach. This might not be applicable here (because
there is no other bios), but it still "feels" safer.
> On the other hand, this is a new recipe and this may not be super
> critical. Especially if you meant that only OVMF will not support
> installing bios.bin in sysroot. Maybe all is needed is some
> clarification in the commit message.
Care to suggest something? ;-) To me, "traditional usage of ovmf ... is
no longer supported" already says that this is a statement about ovmf,
not the bios parameter, so I'm not sure how to reword this.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
next prev parent reply other threads:[~2017-01-23 7:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-20 14:12 [PATCH v4 00/12] UEFI + Secure Boot + qemu Patrick Ohly
2017-01-20 14:12 ` [PATCH v4 01/12] acpica: move from meta-oe to OE-core Patrick Ohly
2017-01-20 14:12 ` [PATCH v4 02/12] acpica: work around flex 2.6.2 code generation issue Patrick Ohly
2017-01-20 14:54 ` Patrick Ohly
2017-01-22 4:00 ` Khem Raj
2017-01-30 19:53 ` Denys Dmytriyenko
2017-01-30 19:55 ` Khem Raj
2017-01-20 14:12 ` [PATCH v4 03/12] ovmf: move from meta-luv to OE-core Patrick Ohly
2017-01-20 14:12 ` [PATCH v4 04/12] ovmf: explicitly depend on nasm-native Patrick Ohly
2017-01-20 14:12 ` [PATCH v4 05/12] ovmf: deploy firmware in image directory Patrick Ohly
2017-01-23 7:23 ` Ricardo Neri
2017-01-23 7:45 ` Patrick Ohly [this message]
2017-01-27 3:25 ` Ricardo Neri
2017-01-27 15:32 ` Patrick Ohly
2017-01-20 14:12 ` [PATCH v4 06/12] ovmf_git.bb: enable parallel compilation Patrick Ohly
2017-01-20 14:12 ` [PATCH v4 07/12] ovmf_git.bb: enable Secure Boot Patrick Ohly
2017-01-20 14:12 ` [PATCH v4 08/12] runqemu: fix undefined variable reference in check_arg_path() Patrick Ohly
2017-01-20 14:12 ` [PATCH v4 09/12] runqemu: also accept -image suffix for rootfs parameter Patrick Ohly
2017-01-20 14:12 ` [PATCH v4 10/12] runqemu: support UEFI with OVMF firmware Patrick Ohly
2017-01-20 14:12 ` [PATCH v4 11/12] ovmf: build image which enrolls standard keys Patrick Ohly
2017-01-20 14:12 ` [PATCH v4 12/12] ovmf: remove BGRT patch Patrick Ohly
2017-01-20 14:23 ` ✗ patchtest: failure for UEFI + Secure Boot + qemu (rev5) Patchwork
2017-01-23 7:27 ` [PATCH v4 00/12] UEFI + Secure Boot + qemu Ricardo Neri
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=1485157551.20333.14.camel@intel.com \
--to=patrick.ohly@intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=ricardo.neri-calderon@linux.intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.