From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53314) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6dBk-0002HY-8N for qemu-devel@nongnu.org; Tue, 06 Aug 2013 05:04:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V6dBe-0001Vv-8r for qemu-devel@nongnu.org; Tue, 06 Aug 2013 05:04:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34143) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6dBe-0001TY-1y for qemu-devel@nongnu.org; Tue, 06 Aug 2013 05:04:14 -0400 Date: Tue, 6 Aug 2013 11:04:03 +0200 From: Kevin Wolf Message-ID: <20130806090403.GE3117@dhcp-200-207.str.redhat.com> References: <1375728247-1306-1-git-send-email-charlie@ctshepherd.com> <1375728247-1306-4-git-send-email-charlie@ctshepherd.com> <20130805192347.GB4872@kerneis.info> <51FFFDF6.4060602@ctshepherd.com> <20130805200524.GD4872@kerneis.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130805200524.GD4872@kerneis.info> Subject: Re: [Qemu-devel] [PATCH 3/5] Convert BlockDriver to explicit coroutine annotations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gabriel Kerneis Cc: stefanha@gmail.com, Charlie Shepherd , qemu-devel@nongnu.org, pbonzini@redhat.com Am 05.08.2013 um 22:05 hat Gabriel Kerneis geschrieben: > On Mon, Aug 05, 2013 at 08:33:10PM +0100, Charlie Shepherd wrote: > > Yes that does merit some explanation. > > Thanks for the details. > > > qemu_co_queue_run_restart is a bit different. It is only called from > > coroutine_swap in qemu-coroutine.c, and it enters coroutines that > > were waiting but have now moved to the runnable state by the actions > > of the most recent coroutine (I believe). I think we discussed this > > on IRC on Thursday? It only calls qemu_coroutine_enter, and cannot > > yield, so again I removed the annotation. I'll add these > > explanations to the commit message. > > Or maybe split those in different commits altogether? I find it often easier to > review many small commits than a big one, each focused on an "atomic" change. Yes, please. One logical change per commit, and no changes that aren't mentioned in the commit message. Kevin