qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] dmg: fix ->open failure


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH] dmg: fix ->open failure
Date: Tue, 12 Jan 2010 10:25:56 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-3.fc11 Thunderbird/3.0

Am 11.01.2010 18:47, schrieb Christoph Hellwig:
> On Mon, Jan 11, 2010 at 03:11:52PM +0100, Kevin Wolf wrote:
>>> Ok, if you start talking about layering, we can have a fundamental
>>> discussion on this topic and why the layering is broken anyway.
>>> Logically, we have image formats like qcow2, VMDK and raw, and they are
>>> stored in files, on CD-ROMs or general block devices. From a layering
>>> perspective, it is wrong to include the latter in the raw format driver
>>> in the first place.
>>
>> Actually, I think the differentiation between raw files and host_* is at
>> the same level as protocols are. Probably they should be implemented
>> very similarly.
>>
>> Do you think it's possible/worth the effort to try putting things
>> straight here?
> 
> So what you want is basically:
> 
>  - hdev_* and file as protocols in addition to nbd/ftp/http/..
>  - a raw image format that can be used ontop of any protocol instead of
>    an image format

Yes, this is pretty much what I was thinking of.

> That would indeed be a much better, not to say actually logical
> layering.  The raw image format would be more or less a no-op just
> stacking ontop of the protocol.  If we can find a way to implement this
> efficiently it might be the way to go.

Right, getting it done for raw without losing performance was more or
less my only concern. I mean, remapping directly to the protocol in
bdrv_open is exactly what we want to avoid. The question is if stubs to
pass requests down to the protocol are really that expensive. It
shouldn't be much more than two additional function calls.

Kevin




reply via email to

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