From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LaAEL-0007EU-QB
	for qemu-devel@nongnu.org; Thu, 19 Feb 2009 09:50:25 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LaAEJ-0007E7-Dz
	for qemu-devel@nongnu.org; Thu, 19 Feb 2009 09:50:24 -0500
Received: from [199.232.76.173] (port=57051 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LaAEJ-0007E4-87
	for qemu-devel@nongnu.org; Thu, 19 Feb 2009 09:50:23 -0500
Received: from mail-qy0-f20.google.com ([209.85.221.20]:59568)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1LaAEI-0002TU-SA
	for qemu-devel@nongnu.org; Thu, 19 Feb 2009 09:50:23 -0500
Received: by qyk13 with SMTP id 13so815113qyk.10
	for <qemu-devel@nongnu.org>; Thu, 19 Feb 2009 06:50:21 -0800 (PST)
Message-ID: <499D7168.2050008@codemonkey.ws>
Date: Thu, 19 Feb 2009 08:49:12 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Machine description as data prototype, take 3
References: <87iqnh6kyv.fsf@pike.pond.sub.org>
	<871vtuafdr.fsf@pike.pond.sub.org>
In-Reply-To: <871vtuafdr.fsf@pike.pond.sub.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org


> diff --git a/hw/dt.c b/hw/dt.c
> +

>   

Please remove the ^Ls.  They don't render properly in my mail client.

> +/* Host Configuration */
> +
> +typedef struct dt_host {
> +    /* connection NICs <-> VLAN */
> +    tree *nic[MAX_NICS];
> +    VLANState *nic_vlan[MAX_NICS];
> +    /* connection drives <-> controller */
> +    tree *drive_ctrl[MAX_DRIVES];
> +    BlockDriverState *drive_state[MAX_DRIVES];
> +} dt_host;
>
>   

typedef struct DeviceTreeHost
{
} DeviceTreeHost.

I'm not sure this structure is going to scale well as we introduce more 
types of host devices.  You don't necessarily need to address the host 
configuration file part of this at this stage.

For instance, I think it would be perfectly fine to require to start 
with that the command line configuration matches the describe machine 
file.  For instance, if you see:

-net tap -net nic,model=rtl8139

Then you should search for an rtl8139 and configure the node to be on 
vlan=0.  If an rtl8139 doesn't exist, throw an error.

The long term goal, would be to have a mechanism to modify the tree in a 
generic way and the -net nic code would end up looking like:

node = find_next_device("type=nic,model=rtl8139");
if (!node) {
   node = find_bus("type=pcibus");
   if (!node)
       bail out
   node = add_node_to_bus(node, 
"type=nic,model=rtl8139,remaining_description_of_rtl8139");
   if (!node)
       bail out
}

attach_nic_to_vlan(vlan, node);

> +static dt_driver *
> +dt_driver_by_name(const char *name)
>   

While I'm not wildly opposed to this style (it's nice for grepping), 
most of the rest of the code doesn't do this (it keeps it on the same line).

Regards,

Anthony Liguori