From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48047) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R49Vm-00052r-J6 for qemu-devel@nongnu.org; Thu, 15 Sep 2011 06:49:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R49Vl-0000Ix-HX for qemu-devel@nongnu.org; Thu, 15 Sep 2011 06:49:42 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:54911) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R49Vl-0000Ir-Eg for qemu-devel@nongnu.org; Thu, 15 Sep 2011 06:49:41 -0400 Received: by yib2 with SMTP id 2so2442790yib.4 for ; Thu, 15 Sep 2011 03:49:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110915063121.GW21417@redhat.com> References: <4E70EC90.8000904@us.ibm.com> <20110915063121.GW21417@redhat.com> Date: Thu, 15 Sep 2011 11:49:40 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 Thu, Sep 15, 2011 at 7: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. =A0A QOM >> path name >> consists of a named device, followed by a series of properties which >> may or may >> not refer to other devices. =A0For instance, all of the following are >> valid paths: >> >> =A0/i440fx/piix3/i8042/aux >> =A0/i440fx/slot[1.0]/i8042/aux >> =A0/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 Yes, it's not clear to me whether the OF device path will be orthogonal to QOM or not. Another part where I am not sure yet: "Device names are completely independent of pathnames. For devices that ar= e no user created, device names should be treated as opaque blobs with absolutel= y no semantic meaning." What does this mean? Perhaps you're saying that: create_object('rtl8139', 'my-nic') pci_bus_name =3D resolve_path('/i440fx') set_object_property(pci_bus_name, 'slot[2.0]', 'my-nic') The device name is a unique identifier that can be used to select a specific device. The path is a relative way of selecting devices given a chain of properties - you only use property names in a path, not device names. Is this correct? For convenience I imagine people would prefer this: create_object('rtl8139', 'my-nic') set_object_property('/i440fx', 'slot[2.0]', 'my-nic') So here set_object_property() detects that there is a '/' in the device name. Therefore it treats the argument as a path instead of a device name. We'd need to add the constraints that paths always start with '/' and device names may not contain '/'. Anyway, did I understand the independence of paths and device names correct= ly? Stefan