From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDXwH-0003xo-UH for qemu-devel@nongnu.org; Mon, 17 Sep 2012 05:48:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TDXwD-00006q-JN for qemu-devel@nongnu.org; Mon, 17 Sep 2012 05:48:25 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:56598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDXwD-00006Z-D0 for qemu-devel@nongnu.org; Mon, 17 Sep 2012 05:48:21 -0400 Received: by dadn15 with SMTP id n15so50949dad.4 for ; Mon, 17 Sep 2012 02:48:20 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5056F1DD.3020505@redhat.com> Date: Mon, 17 Sep 2012 11:48:13 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <949d83d4c80e0ba8629e7dd930d2955759e64757.1347871922.git.peter.crosthwaite@petalogix.com> In-Reply-To: <949d83d4c80e0ba8629e7dd930d2955759e64757.1347871922.git.peter.crosthwaite@petalogix.com> Content-Type: text/plain; charset=ISO-8859-1 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 A. G. Crosthwaite" Cc: edgar.iglesias@gmail.com, crwulff@gmail.com, qemu-devel@nongnu.org Il 17/09/2012 11:02, Peter A. G. Crosthwaite ha scritto: > First revision of fdt generic infrastructure. These modules allow > for fdt generic machine models, which create machines to match a device > tree specification. Ok, so here is the famous coroutine-based FDT generation. :) It does look pretty, to be fair. 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 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? It would be nice if you included some simple qtest test cases. They would generate a few machines with different device trees and check that the output of "info qtree" matches somewhat the device tree. Rough checks should not be hard to implement, and would provide some guidance to people who want to hack the code. Paolo