[Top][All Lists]
[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
>