qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] raw: Use the right host device driver for open/create
Date: Fri, 04 Dec 2009 09:39:28 +0100	[thread overview]
Message-ID: <4B18CAC0.2080400@redhat.com> (raw)
In-Reply-To: <20091130205120.GA6053@lst.de>

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

  parent reply	other threads:[~2009-12-04  8:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-30 15:54 [Qemu-devel] [PATCH] raw: Use the right host device driver for open/create Kevin Wolf
2009-11-30 20:51 ` Christoph Hellwig
2009-12-03 17:43   ` Anthony Liguori
2009-12-04  8:39   ` Kevin Wolf [this message]
2009-12-11  9:04     ` Kevin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B18CAC0.2080400@redhat.com \
    --to=kwolf@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=hch@lst.de \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).