From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41761) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4kOI-0003rs-Fx for qemu-devel@nongnu.org; Fri, 16 Sep 2011 22:12:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4kOH-0004U5-3g for qemu-devel@nongnu.org; Fri, 16 Sep 2011 22:12:26 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:59831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4kOG-0004Ty-W4 for qemu-devel@nongnu.org; Fri, 16 Sep 2011 22:12:25 -0400 Received: by ywm39 with SMTP id 39so4044765ywm.4 for ; Fri, 16 Sep 2011 19:12:24 -0700 (PDT) Message-ID: <4E740203.2050705@codemonkey.ws> Date: Fri, 16 Sep 2011 21:12:19 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E70EC90.8000904@us.ibm.com> <20110915063121.GW21417@redhat.com> <4E71FAD9.1000405@codemonkey.ws> <4E7374EB.2050407@codemonkey.ws> <20110917011110.GF20455@zapo> In-Reply-To: <20110917011110.GF20455@zapo> Content-Type: text/plain; charset=UTF-8; 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: "Edgar E. Iglesias" Cc: Peter Maydell , Gleb Natapov , Jan Kiszka , Markus Armbruster , qemu-devel , Gerd Hoffmann , John Williams On 09/16/2011 08:11 PM, Edgar E. Iglesias wrote: > On Fri, Sep 16, 2011 at 11:10:19AM -0500, Anthony Liguori wrote: >> On 09/16/2011 09:46 AM, John Williams wrote: >>> On Thu, Sep 15, 2011 at 11:17 PM, 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. >>>> >>>>> 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. >>> >>> That need not be the case - with the >>> >>> link=<&target> >>> >>> syntax, device trees can be topologically accurate descriptions - this >>> is part of our still-unreviewed patchset, >> >> It's not unreviewed. Any type of machine configuration needs to be >> done using qdev/qom factory interfaces, not implementing custom >> logic tied to a config format. >> >> Can you construct OF paths based on link attributes? What would >> that look like in practice? >> >>> Another counter-example - our device trees are autogenerated out of a >>> high level system synthesis tool. One path is a device tree for QEMU >>> and kernel configuration, the other is to actually create the system >>> based on a high level design specification. >> >> That's all well and good, but the mechanism that I think is >> important to have in QEMU is a programmatic interface for >> constructing and manipulating the guest devices. A config file is >> not a programmatic interface. You can implement config file support >> in terms of a programmatic interface but implementing the later in >> terms of the former is extremely painful. > > I agree, but I also thinik that we have to be a bit pragmatic It's not pragmatic to leave something that's mostly broken alone and tack on something new that replicates the function to gain a new feature. It just results in more cruft and makes it harder to ever fix the real problem. > in the > sense that if the external interfaces won't be available until years > from now, we should take iternmediate steps. These are the intermediate steps: http://wiki.qemu.org/Features/QOM#TODO We really aren't that far away from fixing qdev and making all of these problems go away. > We've all got imaginary interfaces in our minds, but as long as > these are nowhere near reality, They are very much reality and they aren't imaginary. Code exists, we just need to move in a common direction here and spend some time fixing past mistakes. Regards, Anthony Liguori