Re: [Qemu-devel] [RFC PATCH 0/7] BlockBackends, nodes and guest devices

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 4461 bytes --]

On 23.06.2016 16:36, Kevin Wolf wrote:
> I am relatively confident to say that everything that should use a
> BlockBackend, does so by now. Almost all users create their own anonymous
> BlockBackend internally and use that. The user configures the BB only
> indirectly using the configuration methods of the user that the BB belongs to.
> 
> There is one exception, which are guest devices. There the user is expected to
> manually set up a BlockBackend and pass it to the device. This requires that
> users understand the difference between node and BlockBackends and manage both
> kinds of objects. This is a rather nasty interface.
> 
> My goal is that we allow a user (management tool) to ignore that BlockBackends
> exist as separate entities in qemu. Ideally we could fully make them an
> implementation detail, but I'm not sure to which degree we can do that for
> compatibility reasons. But what I'm pretty sure we can do is provide interfaces
> that address everything using either node names or (qdev) device names, so that
> you don't have to manage BlockBackends if you don't want to.
> 
> This involves several steps, and for most of them this series contains an
> example patch that shows what this could look like:
> 
> 1. Accept node-name in -device drive=... and create an internal anonymous BB
>    for devices configured this way. This is the way to create devices that
>    completely avoid legacy interfaces using the BB name.
> 
> 2. Update all QMP commands touching block devices. There are two kinds of them,
>    concerning either the guest device (which the BlockBackend is logically part
>    of, even though it's not implemented this way) or the actual backend
>    (BlockDriverState/node level)
> 
>    * Device level commands: Accept a guest device ID instead of BB name to
>      identify the BlockBackend the command works on. As device IDs and BB names
>      don't share a single namespace, we'll need a new QMP argument for this.
> 
>    * Node level commands: We need to complete the conversion that makes
>      commands accept node names instead of BlockBackend names. In some places
>      we intentionally allow only BlockBackends because we don't know if the
>      command works in other places than the root. This is okay, but we can
>      accept node names anyway. We just need to check that the node is a root
>      node as expected.
> 
> 3. Remove all BlockBackend options from blockdev-add. This has already happened
>    partially (e.g. WCE flag), but at least id, rerror, werror are still there.
>    This is a very incompatible change, but we declared blockdev-add
>    experimental, so I think it's acceptable.
> 
> 4. Add BlockBackend options as qdev properties to all block devices.
> 
> 5. Add a way on the command line to create block nodes that have a node-name
>    and don't have a BlockBackend. blockdev-add already supports this (and after
>    implementing 3. it will be the only mode supported by blockdev-add), but we
>    can't do this on the command line yet. You always get a BB with -drive.
> 
>    This might finally become the -blockdev we were talking about at the very
>    beginning of the block layer generalisation work.
> 
> So this is my plan. It's pretty radical, but I think we really must do
> something about our interfaces. Having nodes, BlockBackends and guest devices
> to manage is just too much and doesn't really make sense. Making BlockBackends
> visible in the external API essentially only as aliases for either node names
> or guest devices (and that only for compatibility, not when using blockdev-add/
> -blockdev) feels to me like the right thing to do.
> 
> But of course I'm aware that there probably isn't a clear right or wrong, and
> that I might be missing important details, so this needs to be discussed in
> advance before I go and implement the full thing instead of just small example
> patches.
> 
> So please let me know what you guys think about this plan.

I agree that the current interface is confusing because of the BB layer
that the user (unnecessarily) needs to care about. I don't think we
absolutely have to do something about it, but your plan is reasonable
and I do consider it an improvement.

I'm not sure if WCE truly is a guest device property, but adding it as a
guest device property and then syncing it to the BB makes sense (as done
in patch 7).

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 498 bytes --]