On Fri, Sep 16, 2011 at 06:47:56PM +0100, Peter Maydell wrote:
> On 16 September 2011 17:33, Gleb Natapov <g...@redhat.com> wrote:
> > On Thu, Sep 15, 2011 at 09:45:33PM +0100, Peter Maydell wrote:
> >> On 15 September 2011 21:29, Gleb Natapov <g...@redhat.com> wrote:
> >> > 16650A is not a device. ISA card it resides on is a device.
> >>
> >> The 16550A is an encapsulated set of functionality with some
> >> well defined interfaces ("I provide a set of memory mapped
> >> registers", "I have an output gpio line (irq)"), which we
> >> need to be able to compose into other things (lots of models
> >> use a 16550A one way or another, not just the ISA serial card),
> >> connect up (ie connect that irq to an appropriate interrupt
> >> controller, map the registers in system memory or under ISA
> >> or whatever), and configure (eg specify the backend chardev).
> >>
> >> I don't think there's any difference at all between that
> >> and (say) the NE2000 PCI model, which also is encapsulated
> >> functionality with well defined interfaces that we need to
> >> be able to compose and connect and configure. We should be
> >> using the same implementation and abstractions for both
> >> cases.
> >>
> > IDE is another such device (it was ISA later converted to PCI).
> > As far as I understand your view of UART is the same as mine.
> > It is not a whole device, but only a part of it.
>
> If we have the same view of the UART then one of us is rather
> misunderstanding the other (could be me).
>
May be.
> I don't care whether you apply the label "device" to the
> UART, but I definitely want it to be exactly the same kind
> of QEMU "object", in terms of how you implement it and use it,
> as a PCI NE2000 model or an ISA serial card or an ARM-Cortex-A8
> CPU model or a "vexpress-a9" board model.
>
> As it happens, personally I think "device" is a pretty
> reasonable label to use for all these things, since we're going
> to use it anyway for the QEMU objects which happen to correspond
> to ISA cards or PCI cards or whatever.
>
I am not arguing with that. The argument is about what devices hierarchy
in QMEU should be, not what to call "device" and what not to.
--
Gleb.
