qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 21/24] qcow2: add qcow2_open_conversion_target()


From: Devin Nakamura
Subject: Re: [Qemu-devel] [RFC 21/24] qcow2: add qcow2_open_conversion_target()
Date: Tue, 2 Aug 2011 00:37:45 -0400

On Mon, Aug 1, 2011 at 11:26 AM, Kevin Wolf <address@hidden> wrote:
> Am 29.07.2011 06:49, schrieb Devin Nakamura:
>> Still in very raw form.  Not likely to work yet
>>
>> Signed-off-by: Devin Nakamura <address@hidden>
>
> I don't think it's quite as easy.
>
> The problem is that qcow2 will access the image header in some places,
> for example when growing the L1 or refcount table. You need to make sure
> that it doesn't destroy the source format header, but writes to the
> target format header at a different offset.
This is why I've made sure to size the L1 and refcount tables so they
wont need to be resized. But I suppose that's really a balancing act
that's likely to break if someone makes changes to the current code,
or when snapshots are implemented

> I think much of qcow2_open and qcow2_open_conversion_target could be the
> same. That is, both could call a common function that takes a parameter
> for the header offset.
I'm almost certain I could do that (considering I lifted a lot of the
code for qcow2_open_conversion_target from qcow2_open)
> The other part of qcow2_open_conversion_target (creating a new header
> and a basic L1/refcount table) could possibly be shared with
> qcow2_create2, though I'm not quite as sure about this one.


>> +    //TODO: double check this, it seems a bit fishy
>
> That's my impression of the whole operation, too. :-)
>
> This is why I thought it would be nice to share this code with normal
> image creation. Then we have this fishy code at least only once.
>
> Kevin
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]