From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Bok-0001VC-7y for qemu-devel@nongnu.org; Thu, 15 Sep 2011 09:17:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4Bob-0003lg-3c for qemu-devel@nongnu.org; Thu, 15 Sep 2011 09:17:26 -0400 Received: from mail-gw0-f53.google.com ([74.125.83.53]:63876) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Boa-0003lR-Tq for qemu-devel@nongnu.org; Thu, 15 Sep 2011 09:17:16 -0400 Received: by gwj20 with SMTP id 20so2604633gwj.12 for ; Thu, 15 Sep 2011 06:17:16 -0700 (PDT) Message-ID: <4E71FAD9.1000405@codemonkey.ws> Date: Thu, 15 Sep 2011 08:17:13 -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 , 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? get_fw_dev_path() won't exist in QOM. The fact that it exists in qdev is a problem with qdev. > This function generates Open Firmware device path. The function generates *a* OF device path. OF is not a canonical representation of arbitrary hardware. It's a representation chosen (usually by a human) of what information about the hardware is needed by the OS-level software. If you look at what other folks have done with OF integration in QEMU, you'll see a recurring theme of two OF trees, one used to create the hardware and the other that is actually exposed to the guest. The reason you need two is because guests sometimes expect very specific things that you really can't generate programmatically in every circumstance. > 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? All of the information needed to generate an OF tree is available as device properties. To the extent that you need to knowledge of each bus to generate a OF path component, you'll need some extra knowledge of each bus to do that (just like with qdev today). But that knowledge will definitely not be part of QOM. Paths are not part of QOM. They're representations used by client software to navigate the QOM graph. There is no real need to make paths part of QOM explicitly. Regards, Anthony Liguori