From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Bg7-0006y3-Ak for qemu-devel@nongnu.org; Thu, 15 Sep 2011 09:08:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4Bg5-0001th-Vg for qemu-devel@nongnu.org; Thu, 15 Sep 2011 09:08:31 -0400 Received: from mail-gx0-f181.google.com ([209.85.161.181]:34376) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Bg5-0001tU-TJ for qemu-devel@nongnu.org; Thu, 15 Sep 2011 09:08:29 -0400 Received: by gxk9 with SMTP id 9so3161757gxk.12 for ; Thu, 15 Sep 2011 06:08:28 -0700 (PDT) Message-ID: <4E71F8C9.3030300@codemonkey.ws> Date: Thu, 15 Sep 2011 08:08:25 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E70EC90.8000904@us.ibm.com> <20110915063121.GW21417@redhat.com> In-Reply-To: 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: Stefan Hajnoczi Cc: Peter Maydell , Anthony Liguori , Gleb Natapov , Jan Kiszka , Markus Armbruster , qemu-devel , Gerd Hoffmann , "Edgar E. Iglesias" On 09/15/2011 05:49 AM, Stefan Hajnoczi wrote: > 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: >> 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. It's orthogonal to QOM. > Another part where I am not sure yet: > "Device names are completely independent of pathnames. For devices that are no > user created, device names should be treated as opaque blobs with absolutely no > semantic meaning." > > What does this mean? Perhaps you're saying that: > create_object('rtl8139', 'my-nic') > pci_bus_name = resolve_path('/i440fx') > set_object_property(pci_bus_name, 'slot[2.0]', 'my-nic') More specifically: def resolve_path(pathname): ... qmp.create_object('rtl8139', 'my-nic') pci_bus_name = resolve_path('/i440fx') qmp.set_object_property(pci_bus_name, 'slot[2.0]', 'my-nic') Paths are a concept of the client. Maybe we add some path resolution logic to QMP as a convenience to help keep clients consistent with each other but from a strict perspective, a canonical path representation doesn't exist in QOM. > 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? With the exception of the very first component in the path, yes, in the path representation I proposed property names are used as the remaining components. > 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 '/'. Yes, this is exactly how my python client code works FWIW. But set_object_property is a local function to the client, not a function of QMP. Again, we don't need to be this strict in the QMP interface but from a QOM design perspective, I think the separation is important. > Anyway, did I understand the independence of paths and device names correctly? Yup. Regards, Anthony Liguori > Stefan >