From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Cqs-0002W8-E6 for qemu-devel@nongnu.org; Thu, 15 Sep 2011 10:23:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4Cqm-0003Au-Sw for qemu-devel@nongnu.org; Thu, 15 Sep 2011 10:23:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9953) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Cqm-0003Ai-Lr for qemu-devel@nongnu.org; Thu, 15 Sep 2011 10:23:36 -0400 Date: Thu, 15 Sep 2011 17:23:30 +0300 From: Gleb Natapov Message-ID: <20110915142329.GB11524@redhat.com> References: <4E70EC90.8000904@us.ibm.com> <20110915063121.GW21417@redhat.com> <4E71FAD9.1000405@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E71FAD9.1000405@codemonkey.ws> Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , Jan Kiszka , qemu-devel , Markus Armbruster , Gerd Hoffmann , "Edgar E. Iglesias" On Thu, Sep 15, 2011 at 08:17:13AM -0500, Anthony Liguori wrote: > 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. > I do not need get_fw_dev_path() as such. I need the way to generate OF device path for a device. I hope you are not saying that the fact that we generate OF path is the problem of qdev. OF device path is an ABI between QEMU and a firmware. Firmware can't do much with QOM device paths. > >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. > Of course it is chosen by human, just like QOM is the representation chosen by human :) But human made sure that it presents enough information for OS level software to unambiguously determine a device a path points too. > 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. > With qdev buses are different from devices so it is very clear where to put that extra knowledge (inside get_fw_dev_path callback of a bus). How are you going to do that with QOM? As you said in your other email QOM is a graph, so dumb recursion will not work like it did in qdev. At each node you need to know which link to take. > 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. > I am not saying there is. I just what to make sure that we will not regress by moving to QOM. -- Gleb.