From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7Esm-0001yR-3V for qemu-devel@nongnu.org; Wed, 07 Aug 2013 21:19:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7Ese-00084T-NQ for qemu-devel@nongnu.org; Wed, 07 Aug 2013 21:19:15 -0400 Received: from mail6.webfaction.com ([74.55.86.74]:34260 helo=smtp.webfaction.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7Ese-00083R-IO for qemu-devel@nongnu.org; Wed, 07 Aug 2013 21:19:08 -0400 Message-ID: <5202F20B.7040304@ctshepherd.com> Date: Thu, 08 Aug 2013 02:19:07 +0100 From: Charlie Shepherd MIME-Version: 1.0 References: <1375728247-1306-1-git-send-email-charlie@ctshepherd.com> <1375728247-1306-6-git-send-email-charlie@ctshepherd.com> <20130805201516.GE4872@kerneis.info> In-Reply-To: <20130805201516.GE4872@kerneis.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 5/5] Convert block layer callers' annotations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gabriel Kerneis Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, stefanha@gmail.com On 05/08/2013 21:15, Gabriel Kerneis wrote: > On Mon, Aug 05, 2013 at 08:44:07PM +0200, Charlie Shepherd wrote: >> This patch updates the callers of block layer functions converted to explicit >> coroutine_fn annotation in the previous patch. > It looks like this patch is made of three parts: > - updating the annotations, following the rule "caller of coroutine_fn must be > coroutine_fn", > - introducing a run_handler function in qemu-img.c, > - replacing bdrv_* by bdrv_*_sync in qemu-io-cmds.c. > > The first one is purely mechanical and boring. The second one is moderately > inventive (note that I did not review the code in detail). The third one is > simple but definitely deserves some explanation. Again, I think this could be > split in three different patches, with an expanded commit message. Ok thanks this seems like a logical way to split them up. Charlie