From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDar3-0004KQ-WE for qemu-devel@nongnu.org; Mon, 17 Sep 2012 08:55:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TDaqy-0002i6-2k for qemu-devel@nongnu.org; Mon, 17 Sep 2012 08:55:13 -0400 Received: from mx3-phx2.redhat.com ([209.132.183.24]:46661) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDaqx-0002gE-Qb for qemu-devel@nongnu.org; Mon, 17 Sep 2012 08:55:08 -0400 Date: Mon, 17 Sep 2012 08:55:05 -0400 (EDT) From: Paolo Bonzini Message-ID: <2122228866.405132.1347886505085.JavaMail.root@redhat.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v0 07/10] fdt_generic: First revision List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: edgar iglesias , crwulff@gmail.com, qemu-devel@nongnu.org > > However, as things stand there is nothing (I think) that really requires > > coroutines. A simple 2-pass initialization would do, with links and > > irqs connected on the second pass. > > I'm just trying to be a little more general. For more complex setups > we may in the future want to resolve dependencies at different phases > of the machine init process. Do you have any examples of things that are more complicated than "build everything" followed by "resolve everything"? > That and two pass is brutally ugly in code (and > in-efficient) as you need to tag passes. Not sure I follow, but I can't of course promise aesthetics without having written any code. > I'm wondering how your patch fares > > in terms of error handling for example; can you end up with > > partially-uninitialized devices or infinite loops? If so, why not? > > Deadlock looping shouldnt happen if thats what your worried about. > Each device is instantiated before its able to yield (waiting on > another) and all devices are inited before you reach that > all-threads-are-yielded point. Essentially your "first-pass" as you > suggested above is complete before before every thread is yielded, > which makes deadlock impossible with current usages. Ok, so something checks the syntax before initialization runs. Pao