[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/3] block: Add QMP support for streaming to an
From: |
Alberto Garcia |
Subject: |
Re: [Qemu-devel] [PATCH 2/3] block: Add QMP support for streaming to an intermediate layer |
Date: |
Tue, 17 Mar 2015 16:40:51 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
On Tue, Mar 17, 2015 at 09:22:55AM -0600, Eric Blake wrote:
> > The BlockJobInfo object returned by query-block-jobs identifies
> > the owner of the job using the 'device' field. If jobs can be in
> > any intermediate node then we cannot simply rely on the device
> > name. We also cannot simply replace it with a node name because
> > 1) it might not exist and 2) existing libvirt versions expect a
> > device name.
> >
> > So I see several alternatives:
> >
> > a) Add a new 'node-name' field to BlockJobInfo. It's simple,
> > 'device' keeps the current semantics so we don't break
> > compatibility.
> >
> > b) Make 'device' return the device name as it currently does,
> > or the node name if it's not present. The main problem is
> > that libvirt cannot easily know what to expect. On the
> > other hand since both device and node-name share the same
> > namespace the returned value is not ambiguous.
>
> If libvirt is new enough to create the block job via node name
> instead of device name, then it is also new enough to expect a node
> name instead of device name in the returned job information.
That is clear.
> > c) Make 'device' return the same name that was used when
> > the job was created. It's maybe simpler for libvirt than
> > option b), but it would require us to remember how the job
> > was created, possibly in the BlockJob structure. This is
> > personally my least favorite option.
>
> If you're going to reuse 'device' on the creation, then reuse it on
> the reporting.
The problem with c) is that the name is only needed early in the
operation to get a BlockDriverState, we don't use it afterwards.
So returning the same name that was used to request the operation
would force us to keep that information internally, because in the
case of a job owned by a BlockDriverState with both device name
'virtio0' and node name 'node0' it's otherwise impossible to know if
the job was requested using 'virtio0' or 'node0'.
> > d) Create a new query command that returns a different data
> > structure.
> >
> > I would opt for a) or b), but I'd like to hear if you have a
> > different opinion.
>
> I'm kind of leaning towards b).
But note that in the example I just mentioned, if you create a job
using 'node0' to refer to the node, you would still get 'virtio0' in
return, and not 'node0'.
With b) you only get 'node0' if the node does not have a device name.
Berto