From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55298) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4kTe-0004pQ-Pa for qemu-devel@nongnu.org; Fri, 16 Sep 2011 22:18:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4kTd-0005oT-L2 for qemu-devel@nongnu.org; Fri, 16 Sep 2011 22:17:58 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:60278) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4kTd-0005oN-HD for qemu-devel@nongnu.org; Fri, 16 Sep 2011 22:17:57 -0400 Received: by gxk26 with SMTP id 26so5160498gxk.4 for ; Fri, 16 Sep 2011 19:17:57 -0700 (PDT) Message-ID: <4E740352.8050407@codemonkey.ws> Date: Fri, 16 Sep 2011 21:17:54 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E720855.1090501@redhat.com> <20110915142534.GC11524@redhat.com> <4E7219B4.9050109@us.ibm.com> <20110915153838.GE11524@redhat.com> <4E7228BC.9030104@us.ibm.com> <20110915165921.GF11524@redhat.com> <4E723B1B.5070805@codemonkey.ws> <20110915202907.GG11524@redhat.com> <4E726514.1050804@codemonkey.ws> <20110916164757.GB11160@redhat.com> <20110917004804.GD20455@zapo> In-Reply-To: <20110917004804.GD20455@zapo> 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: "Edgar E. Iglesias" Cc: Peter Maydell , Gleb Natapov , Jan Kiszka , qemu-devel , Markus Armbruster , Gerd Hoffmann , Paolo Bonzini On 09/16/2011 07:48 PM, Edgar E. Iglesias wrote: > On Fri, Sep 16, 2011 at 07:47:57PM +0300, Gleb Natapov wrote: >> On Thu, Sep 15, 2011 at 03:50:28PM -0500, Anthony Liguori wrote: >>> On 09/15/2011 03:29 PM, Gleb Natapov wrote: >>>> On Thu, Sep 15, 2011 at 12:51:23PM -0500, Anthony Liguori wrote: >>>>> On 09/15/2011 11:59 AM, Gleb Natapov wrote: >>>>>> On Thu, Sep 15, 2011 at 11:33:00AM -0500, Anthony Liguori wrote: >>>>>>> On 09/15/2011 10:38 AM, Gleb Natapov wrote: >>>>>>>> On Thu, Sep 15, 2011 at 10:28:52AM -0500, Anthony Liguori wrote: >>>>>>>>> On 09/15/2011 09:25 AM, Gleb Natapov wrote: >>>>>>>>> >>>>>>>>> There is no canonical parent link. A device may have multiple (more >>>>>>>>> or less equivalent) parents. >>>>>>>>> >>>>>>>>> What should be treated as the "canonical" link depends on what >>>>>>>>> you're trying to do. In the case of OF, you want to treat the bus >>>>>>>>> as a parent. If a device happens to sit on multiple buses, I'm not >>>>>>>>> really sure what you do. >>>>>>>>> >>>>>>>> Yes, "canonical" is a link to a bus. Can you give an example of a device >>>>>>>> that sits on multiple buses? >>>>>>> >>>>>>> Not all devices buses that they sit on. >>>>>>> >>>>>> Missing "have"? If device has no bus how do you talk to it? Who carries >>>>>> the signal from a cpu to a device? >>>>>> >>>>>>> A good example is our favorite one to debate--the PIIX3. Devices >>>>>> PIIX3 is a collection of devices, not a device. >>>>>> >>>>>>> like the UART don't sit on a bus. They don't have any links at all. >>>>>> In PC UART sits on isa bus. How device can have no links at all? It just >>>>>> glued to a motherboard not touching any wires? >>>>> >>>>> A bus implies a bidirectional relationship. IOW, the device has to >>>>> know that it sits on a ISA bus to be an ISA device. >>>>> >>>> And ISA device with UART on it definitely knows that. > > IMO, this discussion is going nowhere, Partly because assummptions are > beeing made about how hardware "works". > > Hardware works the way it gets designed, and it can be desinged in pretty > much anyway you want. > > When it comes to devives, you can design them in a way so they become very > dependent on a specific bus. But you can also design them in a more genric > way so that they become bus agnostic. Then you just need to connect a bus > adaptor that hooks things up to the particular bus the device needs to be > hooked up to. > > Sometimes, the bus adaptor becomes more like like wrapper that is part > of the logic, other times, the bus adaptor is just a passthru unit. > > QEMU should allow us to model devices in a a bus agnostic way. And this is the problem to fix in qdev. We need to kill buses in qdev. The approach really boils down to: 1) Add unique names to devices (this is needed because buses must have names because they must be addressable). 2) Eliminate any device that has two bus instances in it. I'm pretty sure IDE is the only example of this. 3) Move all BusState functionality to DeviceState and eliminate buses. This is a compatibility breaker but a critical change. Along the way, we also need to refactor properties to support getters/setters and add composition properties and link properties. At some point, we need to introduce the QOM type system to get the full benefits of all of this but that can probably be mechanical once we've completed the above. I think this is all well within the scope of 1.1 and can be done without a tremendous amount of churn in the tree. Regards, Anthony Liguori