On Fri, 2017-07-21 at 07:21 -0400, Tom Rini wrote:
> On Fri, Jul 21, 2017 at 09:47:21AM +0200, Patrick Ohly wrote:
> > On Thu, 2017-07-20 at 18:43 -0400, Tom Rini wrote:
> > > The support for writing vmdk/vdi/qcow2 images has not been converted to
> > > make
> > > use of the IMAGE_CMD infrastructure and instead relies on custom logic for
> > > adding tasks in the right place. Convert these images to making use of
> > > IMAGE_CMD.
> >
> > Thanks for working on this. I still have
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=10204 open for
> > enhancing vmdk/vdi/qcow2.
> >
> > However, your patch doesn't go as far as described in that bug, does it?
> > Instead of allowing, for example, IMAGE_FSTYPES = "wic.vmdk", it merely
> > changes how IMAGE_FSTYPES = "vmdk" is implemented.
> >
> > The current patch has its merits as it simplifies the implementation,
> > but I think it would be worthwhile to go all the way, even if it changes
> > how images are going to be named.
>
> Ah, interesting. I guess the first thing I would argue against is
> saying that hdddirect should be masked. There are reasons to want to
> have a raw image created.
I'm not sure I understand what you mean with "hdddirect should be
masked" - it's been a while that I looked at the code.
> I will take a look into using CONVERSIONCMD for vmdk/qcow2/vdi to allow
> for wic.vmdk to work. But we also must have vmdk.xz work (and fwiw with
> my series you can get arbitrary compression that we support done, I did
> vmdk.xz, qcow2.lzo and vdi.bz2 just for 'fun').
The same is true with CONVERSIONCMD. They can be chained multiple times.
> But I'm not 100% sure that I like changing the normal case from "vmdk"
> to "wic.vmdk" or "hdddirect.vmdk" just to get a disk image to throw at
> ${VM_TECHNOLOGY}.
Yes, that's the biggest user-visible change. Basically the internal
implementation (multiple conversions chained together) becomes visible
in the end-result.
That is a good and a bad thing. The good thing is that it is visible how
the .vmdk image was created. The bad thing is that some users might not
care and get confused.
--
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.
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
