From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTXVw-00068Z-B5 for qemu-devel@nongnu.org; Thu, 05 Mar 2015 10:16:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YTXVr-0000OV-L0 for qemu-devel@nongnu.org; Thu, 05 Mar 2015 10:16:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38416) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTXVr-0000ON-CF for qemu-devel@nongnu.org; Thu, 05 Mar 2015 10:16:35 -0500 Date: Thu, 5 Mar 2015 16:15:52 +0100 From: Kevin Wolf Message-ID: <20150305151552.GF5427@noname.redhat.com> References: <2e1103fe919e6a065dbd2e305f8b9b0fdb687b4e.1424439295.git.berto@igalia.com> <20150305140425.GD5427@noname.redhat.com> <20150305145831.GA750@igalia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150305145831.GA750@igalia.com> Subject: Re: [Qemu-devel] [PATCH 1/3] block: Support streaming to an intermediate layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia Cc: qemu-devel@nongnu.org, Stefan Hajnoczi Am 05.03.2015 um 15:58 hat Alberto Garcia geschrieben: > On Thu, Mar 05, 2015 at 03:04:25PM +0100, Kevin Wolf wrote: > > > The bs parameter is now only used for the following things: > > > > 1. As the default for top > > Right. > > > 2. For error handling: Any errors are reported for bs, even though > > they are actually for top. Is this correct behaviour? It looks > > questionable to me. > > Hmm... I guess you mean when calling block_job_error_action(), I > probably overlooked that. Yes, that and the check whether iostatus is enabled. > > 3. As the BDS that owns the job > > > > My question is whether we can't simply call stream_start() with an > > intermediate node as bs instead of introducing a new parameter. I'm > > not completely sure about the consequences of 3., i.e. moving > > ownership of a block job to some BDS somewhere down the chain, but > > otherwise it should be possible and seems cleaner. > > We can, that was actually the first thing I tried and it does work, > but then I noticed that other parts of the code would need changes, > e.g. qmp_query_block_jobs() must be modified to iterate over all nodes > of each device. > > Since I was also not sure about the consequences of such a change I > opted for the conservative approach. I see. I'm worried about the external API. If we let the root node own the job, we may paint ourselves into a corner with respect to nodes with multiple users and therefore multiple possible root nodes. Kevin