qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] raw: Use the right host device driver for open/


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH] raw: Use the right host device driver for open/create
Date: Fri, 04 Dec 2009 09:39:28 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4

Am 30.11.2009 21:51, schrieb Christoph Hellwig:
> On Mon, Nov 30, 2009 at 04:54:31PM +0100, Kevin Wolf wrote:
>> Users don't expect that they need to specify host_device/cdrom/floppy when
>> "creating" an image on a block device or converting with an device as target.
>> Currently creating as raw leads to 'Error while formatting' whereas using as
>> raw just works.
>>
>> With this patch raw is accepted for both files and host devices. For devices
>> the block driver is transparently changed to host_*.
> 
> I agree that we should allow raw to also cover host devices, but I don't
> like the implementation very much.  Beeing used to specify the format is
> pretty much the only reason to have the name in the block driver anyway,
> and looking it up in one is a bit of a layering violation.

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.

> I'd suggest to either allow multiple formats with the same name and
> looping over them or some sort of alias property in the block driver to
> also match the alias instead.

I don't like taking the same name for multiple formats very much. You
get a bug report with a "raw" image and need to start guessing which of
the many raws could be meant.

Adding some kind of a "parent driver" field to the driver definition and
probing for which of the children is used could work though (it would
basically mean moving the code of this patch into block.c). I'm not sure
if such an abstraction is needed when there is only one user anyway
(same argument as yours with AIO, even though there are two users), but
I'm not opposed to it. It just won't help much in getting the layering
right.

In the end, I don't care too much which way it is implemented, but I do
want to present the right user interface in 0.12.

Kevin




reply via email to

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