From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lbg0w-0001Gl-TG for qemu-devel@nongnu.org; Mon, 23 Feb 2009 13:58:50 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lbg0u-0001FU-Dn for qemu-devel@nongnu.org; Mon, 23 Feb 2009 13:58:49 -0500 Received: from [199.232.76.173] (port=48800 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lbg0u-0001FR-8y for qemu-devel@nongnu.org; Mon, 23 Feb 2009 13:58:48 -0500 Received: from qw-out-1920.google.com ([74.125.92.144]:12569) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lbg0t-0005vR-Nv for qemu-devel@nongnu.org; Mon, 23 Feb 2009 13:58:47 -0500 Received: by qw-out-1920.google.com with SMTP id 4so631420qwk.4 for ; Mon, 23 Feb 2009 10:58:46 -0800 (PST) Message-ID: <49A2F1C7.6000801@codemonkey.ws> Date: Mon, 23 Feb 2009 12:58:15 -0600 From: Anthony Liguori 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> <499D7168.2050008@codemonkey.ws> <87y6vxhx3v.fsf@pike.pond.sub.org> In-Reply-To: <87y6vxhx3v.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: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Markus Armbruster wrote: > Anthony Liguori writes: > > >>> diff --git a/hw/dt.c b/hw/dt.c >>> + >>> >>> >> Please remove the ^Ls. They don't render properly in my mail client. >> > > Many source files contain ^L already. But I'll drop mine if you insist. > My mailer (Thunderbird) expands the ^L into about 20 new lines making the patches difficult to review. >>> +/* 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. >> > > If you insist on CamelCase, IFindThatUglyAndHardToRead, but I can do > that. Just typedef names? > Why? Just convert to the way the rest of the code does it. Conformity feels good, I promise :-) > As to the placement of braces, a quick grep shows the vast majority of > such typedefs to have the brace on the same line as the typedef. > Yeah, that's fine. My bracket placement was not intentional. >> 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. >> > > Conversely, when an optional tree node isn't enabled (e.g. with -net nic > for NICs), silently cut it from the tree. > I'd prefer the first iteration to not modify the tree at all. The specified command line configuration should exactly match whatever the tree specifies. How manipulate the tree in a generic way is IMHO a harder problem that deserves to be addressed in a proper way. >> 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); >> > > Makes sense to me. > > The driver should declare on what kind(s) of bus this device can go. > Yup. Regards, Anthony Liguori