From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36601) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4ItI-0001mZ-9K for qemu-devel@nongnu.org; Thu, 15 Sep 2011 16:50:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4ItF-00023E-Dh for qemu-devel@nongnu.org; Thu, 15 Sep 2011 16:50:36 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:47655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4ItF-000234-AE for qemu-devel@nongnu.org; Thu, 15 Sep 2011 16:50:33 -0400 Received: by yib2 with SMTP id 2so2993187yib.4 for ; Thu, 15 Sep 2011 13:50:32 -0700 (PDT) Message-ID: <4E726514.1050804@codemonkey.ws> Date: Thu, 15 Sep 2011 15:50:28 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E70EC90.8000904@us.ibm.com> <20110915063121.GW21417@redhat.com> <4E720435.3060509@codemonkey.ws> <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> In-Reply-To: <20110915202907.GG11524@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" , Paolo Bonzini 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. > >> The UART has no knowledge of the fact that is mapped behind ISA. >> The UART exposes a public interface (through it's pins) that's >> orthogonal to any buses. >> > The UART itself has no knowledge, yes. But UART does not exists in > vacuum. It is always a part of other device that provides bus logic. > Original PC provided 2 or 4 ISA devices with UART on them. That is how > we need to model them on a PC. You can (or could) easily buy PCI card > with many more additional UARTs. You wouldn't claim that those UARTs are > not on the PCI bus, would you? Let's consider the following. Let's say that we emulated a simpler micro controller that exposes a GPIO interface. Something like an Amtel or maybe even a simple ARM chip. IRL, you would wire the UART pins directly to the GPIO pins and call it a day. There is no bus and there is no intermediate layer. In an everything has a bus world, how does something like this get modelled? >> How do you "walk up the device graph" from a 16650A? What signals >> are you going to send out of the pins to do that? > 16650A is not a device. ISA card it resides on is a device. > >> >> If a device can always do self->parent->parent->parent->send_io(foo) >> then the design is fundamentally broken and you will end up with >> devices that do things that they shouldn't do. >> > Why? Because a serial device has no business calling functions in the i440fx device. It's a layering violation. Regards, Anthony Liguori > > -- > Gleb. >