qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

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