From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHy5g-0001xV-8V for qemu-devel@nongnu.org; Fri, 06 Sep 2013 11:37:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHy5Y-0004VU-Sx for qemu-devel@nongnu.org; Fri, 06 Sep 2013 11:36:56 -0400 Received: from mail6.webfaction.com ([74.55.86.74]:52502 helo=smtp.webfaction.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHy5Y-0004VG-OB for qemu-devel@nongnu.org; Fri, 06 Sep 2013 11:36:48 -0400 Message-ID: <5229F68F.8060704@ctshepherd.com> Date: Fri, 06 Sep 2013 16:36:47 +0100 From: Charlie Shepherd MIME-Version: 1.0 References: <1378477839-7353-1-git-send-email-gabriel@kerneis.info> In-Reply-To: <1378477839-7353-1-git-send-email-gabriel@kerneis.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Introducing CoroCheck and proposal for a blocking_fn annotation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gabriel Kerneis Cc: kwolf@redhat.com, stefanha@gmail.com, qemu-devel@nongnu.org, pbonzini@redhat.com On 06/09/2013 15:30, Gabriel Kerneis wrote: > Note that CoroCheck has been written as a plugin to CIL [5]. Contrary to > CPC, which is still somewhat of a prototype (although a pretty good > one!), CIL is a solid piece of software, packaged in both Fedora and > (very soon) Debian. CoroCheck makes use of the CIL plugin facility which > has not made its way into a released version yet, but this should happen > in the next few months. Therefore, in a not-too-distant future, it is > reasonable to imagine that static checking of QEMU coroutine_fn > annotations could be (an optional) part of QEMU test suite. Adding > blocking_fn annotations would make even more sense in this context. I definitely think static checking of coroutine_fn annotations is the only way to ensure that the QEMU tree is coroutine safe. I think Stefan mentioned a bug that occurred previously due to a function that expected to be called in a coroutine context being called normally. However, I'm not sure it makes sense to use blocking_fn until the convert-block series (which currently needs a respin after Stefan's review) is fully upstreamed. Maybe this patch makes most sense at the start of that series? Charlie