qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Plan for moving forward with QOM


From: Gleb Natapov
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
Date: Fri, 16 Sep 2011 19:47:57 +0300

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.
> >
> >>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.
> 
I am not familiar enough with UART schematic and timings to tell if it
possible, but lets say it is.

> In an everything has a bus world, how does something like this get modelled?
> 
It is a bus. Ad-Hoc one, but still. GPIO pins connected to one or
several devices in order for CPU to communicate with them comprise a
bus.

Is i2c a bus? It calls itself this way. You can use two gpio pins to
implement it. Does it stops to be a bus only because you used gpio pins
to implement it and not a HW controller? Heck, there is 1-wire bus too.

Wikipedia says: "In computer architecture, a bus is a subsystem that
transfers data between components inside a computer, or between
computers". According to his definition what you described above is a
bus.


> >>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.
> 
Ah, yes. I agree. I misunderstood what you were saying. I thought you
meant that having parent link is fundamentally broken and somehow will
cause devices to do things that they shouldn't do.

--
                        Gleb.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]