From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXtc4-0004tE-Io for qemu-devel@nongnu.org; Tue, 17 Mar 2015 11:41:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YXtby-0000te-NX for qemu-devel@nongnu.org; Tue, 17 Mar 2015 11:41:00 -0400 Received: from smtp3.mundo-r.com ([212.51.32.191]:28297 helo=smtp4.mundo-r.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXtby-0000tI-Cj for qemu-devel@nongnu.org; Tue, 17 Mar 2015 11:40:54 -0400 Date: Tue, 17 Mar 2015 16:40:51 +0100 From: Alberto Garcia Message-ID: <20150317154051.GA18262@igalia.com> References: <49b845c4a362ffd64ec78bbe0b165cd7addd2a4b.1424439295.git.berto@igalia.com> <20150305140958.GE5427@noname.redhat.com> <20150311163806.GA5883@igalia.com> <20150312154517.GB7029@noname.redhat.com> <20150317150028.GA21771@igalia.com> <550846CF.10706@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550846CF.10706@redhat.com> Subject: Re: [Qemu-devel] [PATCH 2/3] block: Add QMP support for streaming to an intermediate layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , Jeff Cody , qemu-devel@nongnu.org, Stefan Hajnoczi 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