Re: [PATCH 4/9] ovmf: deploy firmware in image directory

[Patrick Ohly <patrick.ohly@intel.com>]

On Mon, 2017-01-09 at 19:50 -0800, Ricardo Neri wrote:
> On Wed, 2017-01-04 at 11:01 +0100, Patrick Ohly wrote:
> > On Wed, 2016-12-28 at 13:38 -0800, Ricardo Neri wrote:
> > > >  do_install_class-target() {
> > > > -    OVMF_DIR_SUFFIX="X64"
> > > > -    if [ "${TARGET_ARCH}" != "x86_64" ] ; then
> > > > -        OVMF_DIR_SUFFIX="Ia32" # Note the different capitalization
> > > > -    fi
> > > > +    # Traditional location.
> > > >      install -d ${D}${datadir}/ovmf
> > > > +    install -m 0755 ${WORKDIR}/ovmf/OVMF.fd ${D}${datadir}/ovmf/bios.bin
> > > 
> > > Now that I think about it. Installing here does not sever any purpose.
> > > Thus, I think this can be removed by perhaps doing do_install[noexec] =
> > > "1"
> > 
> > I was trying not to break traditional usage patterns. If we keep the
> > "bios" runqemu parameters, then we should also keep the bios.bin file.
> 
> I think OVMF is not a traditional recipe. There are two use cases to
> ponder. 1) a Yocto Project disk image wants to include OVMF along with
> qemu to run a VM from the YP image. 2) we want to run a YP image in a
> host system. I am not sure if someone is interested in 1) and I think
> your use case and LUV's is 2). I think that putting things in the deploy
> directory makes more sense because, as you said, these images will be
> written to. I reckon the the "bios" parameters in runqemu should look
> there. This is not a must for this patchset but something nice to have.

Okay, so let's remove that "traditional location" already in this patch
set. I still want to keep the "bios" parameters in runqemu (because they
might have some other uses), but for OVMF, the only supported approach
will be via the "ovmf" parameters and the deploy directory.

-- 
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.