qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] KVM call minutes 2013-01-29 - Port I/O


From: Anthony Liguori
Subject: Re: [Qemu-devel] KVM call minutes 2013-01-29 - Port I/O
Date: Wed, 30 Jan 2013 15:42:29 -0600
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Benjamin Herrenschmidt <address@hidden> writes:

> On Wed, 2013-01-30 at 17:54 +0100, Andreas Färber wrote:
>> 
>> That would require polymorphism since we already need to derive from
>> PCIDevice or ISADevice respectively for interfacing with the bus...
>> Modern object-oriented languages have tried to avoid multi-inheritence
>> due to arising complications, I thought. Wouldn't object if someone
>> wanted to do the dirty implementation work though. ;)
>> 
>> Another such example is EHCI, with PCIDevice and SysBusDevice
>> frontends,
>> sharing an EHCIState struct and having helper functions operating on
>> that core state only. Quite a few device share such a pattern today
>> actually (serial, m48t59, ...).
>
> This is a design bug of your model :-) You shouldn't derive from your
> bus interface IMHO but from your functional interface, and have an
> ownership relation to the PCIDevice (a bit like IOKit does if my memory
> serves me well).

Ack.  Hence:

SerialPCIDevice is-a PCIDevice
   has-a SerialChipset

The board that exports a bus interface is one object.  The chipset that
implements the functionality is another object.

The former's job in life is to map the bus interface to whatever
interface the functional object expects.  In most cases, this is just a
straight forward proxy of a MemoryRegion.  Sometimes this involves
address shifting, etc.

Regards,

Anthony Liguori

>
> Cheers,
> Ben.



reply via email to

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