From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52472) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3nwo-0003yM-PU for qemu-devel@nongnu.org; Mon, 29 Jul 2013 09:57:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3nwi-00022o-Qc for qemu-devel@nongnu.org; Mon, 29 Jul 2013 09:57:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3nwi-00021m-Hw for qemu-devel@nongnu.org; Mon, 29 Jul 2013 09:57:08 -0400 Message-ID: <51F67496.8010703@redhat.com> Date: Mon, 29 Jul 2013 15:56:38 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1374762197-7261-1-git-send-email-pbonzini@redhat.com> <1374762197-7261-6-git-send-email-pbonzini@redhat.com> <20130729132129.GE10467@dhcp-200-207.str.redhat.com> In-Reply-To: <20130729132129.GE10467@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 05/19] block: make bdrv_co_is_allocated static List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: pl@kamp.de, qemu-devel@nongnu.org, stefanha@redhat.com, Charlie Shepherd Il 29/07/2013 15:21, Kevin Wolf ha scritto: > Am 25.07.2013 um 16:23 hat Paolo Bonzini geschrieben: >> bdrv_is_allocated can detect coroutine context and go through a fast >> path, similar to other block layer functions. >> >> Reviewed-by: Eric Blake >> Signed-off-by: Paolo Bonzini > > It can, but why is this a good idea? What exactly? Dropping bdrv_co_is_allocated from the public API, or not creating always a new coroutine while still dropping bdrv_co_is_allocated? In the end, the answer is simply for consistency. bdrv_co_is_allocated is different from all other APIs in this respect, and I didn't want to choose between making get_block_status the same as is_allocated vs. the same as everything else. > Charlie is working in exactly the opposite direction, namely splitting > the existing functions in a coroutine-only and a synchronous-only part. > We should be clear what we really want here. That's fine---but whatever we do we should do it for all APIs. So this patch is just making things consistent before adding another API. Paolo