From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40688) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4CRZ-0001zZ-Hn for qemu-devel@nongnu.org; Thu, 15 Sep 2011 09:57:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4CRG-0006OD-8q for qemu-devel@nongnu.org; Thu, 15 Sep 2011 09:57:33 -0400 Received: from mail-gw0-f53.google.com ([74.125.83.53]:61421) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4CRF-0006O9-UM for qemu-devel@nongnu.org; Thu, 15 Sep 2011 09:57:14 -0400 Received: by gwj20 with SMTP id 20so2656753gwj.12 for ; Thu, 15 Sep 2011 06:57:13 -0700 (PDT) Message-ID: <4E720435.3060509@codemonkey.ws> Date: Thu, 15 Sep 2011 08:57:09 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E70EC90.8000904@us.ibm.com> <20110915063121.GW21417@redhat.com> In-Reply-To: <20110915063121.GW21417@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Peter Maydell , Anthony Liguori , Jan Kiszka , qemu-devel , Markus Armbruster , Gerd Hoffmann , "Edgar E. Iglesias" On 09/15/2011 01:31 AM, Gleb Natapov wrote: > On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote: >> All device relationships are identified as named properties. A QOM >> path name >> consists of a named device, followed by a series of properties which >> may or may >> not refer to other devices. For instance, all of the following are >> valid paths: >> >> /i440fx/piix3/i8042/aux >> /i440fx/slot[1.0]/i8042/aux >> /i440fx/slot[1.0]/bus/piix3/i8042/aux >> > Have you looked at device paths generated by get_fw_dev_path() in qdev? > This function generates Open Firmware device path. The difference > between OF device path and the examples above is that OF device path has > a meaning outside of QEMU and can be used by firmware to find a device > a path refers too. Will QOM be able to generate them? > > The paths look like: > /pci@i0cf8/ide@1,1/drive@1/disk@0 > /pci@i0cf8/isa@1/fdc@03f1/floppy@1 > /pci@i0cf8/isa@1/fdc@03f1/floppy@0 > /pci@i0cf8/ide@1,1/drive@1/disk@1 > /pci@i0cf8/ide@1,1/drive@0/disk@0 > /pci@i0cf8/scsi@3/disk@0,0 > /pci@i0cf8/ethernet@4/ethernet-phy@0 > /pci@i0cf8/ethernet@5/ethernet-phy@0 > /pci@i0cf8/ide@1,1/drive@0/disk@1 > /pci@i0cf8/isa@1/ide@01e8/drive@0/disk@0 > /pci@i0cf8/usb@1,2/network@0/ethernet@0 > /pci@i0cf8/usb@1,2/hub@1/network@0/ethernet@0 > /rom@genroms/linuxboot.bin > > For isa machines: > /isa/ide@0170/drive@0/disk@0 > /isa/fdc@03f1/floppy@1 > /isa/fdc@03f1/floppy@0 > /isa/ide@0170/drive@0/disk@1 A critical point that I neglected to previously mention is that while qdev has a canonical path (only one path, really) to address a device, QOM does not. That means a different approach is needed to make the graph look like a tree as OF requires. You need something like this: void generate_tree(Device *node) { if (IS_PCI_BUS(node)) { for (i = 0; i < 32; i++) { generate_tree(lookup_device(get_property(node, "slot[%d]", i))); } } else if (IS_ISA_BUS(node)) { .... } else { // leaf node, generate path segment } } There are certainly ways to walk the graph generically (by coloring or following the composition paths) but that won't give you the desired ordering. Regards, Anthony Liguori } > > > -- > Gleb. >