All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 02/14] block: Add blk_new_open()
Date: Fri, 19 Dec 2014 10:26:55 +0100	[thread overview]
Message-ID: <5493EF5F.1010505@redhat.com> (raw)
In-Reply-To: <20141218151952.GE25902@noname.redhat.com>

On 2014-12-18 at 16:19, Kevin Wolf wrote:
> Am 11.12.2014 um 14:20 hat Max Reitz geschrieben:
>> blk_new_with_bs() creates a BlockBackend with an empty BlockDriverState
>> attached to it. Empty BDSs are not nice, therefore add an alternative
>> function which combines blk_new_with_bs() with bdrv_open().
>>
>> Note: In contrast to bdrv_open() which takes a BlockDriver parameter,
>> blk_new_open() does not take such a parameter. This is because
>> bdrv_open() opens a BlockDriverState, therefore it is naturally to be
>> able to set the BlockDriver for that BDS. The fact that bdrv_open() can
>> open more than a single BDS is merely some form of a byproduct.
>>
>> blk_new_open() on the other hand is intended to be used to create a
>> whole tree of BlockDriverStates. Therefore, setting a single BlockDriver
>> does not make much sense. Instead, the drivers to be used for each of
>> the nodes must be configured through the "options" QDict; including the
>> driver of the root BDS.
> This is an interesting point. I generally agree with your reasoning, but
> if we did things right, the same would apply to filename and flags as
> well. But we don't, so we can't remove them now.
>
> I'm actually surprised that leaving out the driver option seem to work
> well enough.

Well, just putting the filename into the QDict won't work thanks to the 
additional parsing that is done on the non-QDict filename; and most 
flags don't have any correspondence in the QDict.

On the other hand, putting the driver name into the QDict is easy enough 
and will do exactly the same as specifying the BlockDriver directly, 
except for some different error messages.

> Should at least a TODO be left here for removing filename and flags?

Yes, will do.

Max

  reply	other threads:[~2014-12-19  9:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-11 13:20 [Qemu-devel] [PATCH 00/14] block: Remove "growable", add blk_new_open() Max Reitz
2014-12-11 13:20 ` [Qemu-devel] [PATCH 01/14] block: Lift some BDS functions to the BlockBackend Max Reitz
2014-12-11 13:20 ` [Qemu-devel] [PATCH 02/14] block: Add blk_new_open() Max Reitz
2014-12-18 15:19   ` Kevin Wolf
2014-12-19  9:26     ` Max Reitz [this message]
2014-12-11 13:20 ` [Qemu-devel] [PATCH 03/14] blockdev: Use blk_new_open() in blockdev_init() Max Reitz
2014-12-11 13:20 ` [Qemu-devel] [PATCH 04/14] block/xen: Use blk_new_open() in blk_connect() Max Reitz
2014-12-11 13:20 ` [Qemu-devel] [PATCH 05/14] qemu-img: Use blk_new_open() in img_open() Max Reitz
2014-12-11 13:20 ` [Qemu-devel] [PATCH 06/14] qemu-img: Use blk_new_open() in img_rebase() Max Reitz
2014-12-11 13:20 ` [Qemu-devel] [PATCH 07/14] qemu-img: Use BlockBackend as far as possible Max Reitz
2014-12-11 13:20 ` [Qemu-devel] [PATCH 08/14] qemu-nbd: Use blk_new_open() in main() Max Reitz
2014-12-11 13:20 ` [Qemu-devel] [PATCH 09/14] qemu-io: Use blk_new_open() in openfile() Max Reitz
2014-12-11 13:20 ` [Qemu-devel] [PATCH 10/14] qemu-io: Remove "growable" option Max Reitz
2014-12-11 13:20 ` [Qemu-devel] [PATCH 11/14] qemu-io: Use BlockBackend Max Reitz
2014-12-11 13:20 ` [Qemu-devel] [PATCH 12/14] block: Clamp BlockBackend requests Max Reitz
2014-12-11 13:20 ` [Qemu-devel] [PATCH 13/14] block: Remove "growable" from BDS Max Reitz
2014-12-11 13:20 ` [Qemu-devel] [PATCH 14/14] block: Keep bdrv_check*_request()'s return value Max Reitz
2014-12-18 15:16 ` [Qemu-devel] [PATCH 00/14] block: Remove "growable", add blk_new_open() 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=5493EF5F.1010505@redhat.com \
    --to=mreitz@redhat.com \
    --cc=armbru@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.