From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] KVM call minutes 2013-01-29 - Port I/O
Date: Wed, 30 Jan 2013 15:42:29 -0600
Message-ID: <877gmu5ovu.fsf@codemonkey.ws>
References: <871ud4gfoa.fsf@elfo.elfo> <5109065B.4060803@suse.de> <51094024.20803@redhat.com> <87vcae8wbk.fsf@codemonkey.ws> <51095049.7090407@suse.de> <1359580074.23274.32.camel@pasglop>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Gerd Hoffmann <kraxel@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	KVM devel mailing list <kvm@vger.kernel.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	Alexander Graf <agraf@suse.de>, qemu-ppc <qemu-ppc@nongnu.org>,
	=?utf-8?Q?Herv=C3=A9?= Poussineau <hpoussin@reactos.org>,
	David Gibson <david@gibson.dropbear.id.au>,
	Alon Levy <alevy@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Andreas =?utf-8?Q?F?= =?utf-8?Q?=C3=A4rber?= <afaerber@suse.de>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-oa0-f48.google.com ([209.85.219.48]:34365 "EHLO
	mail-oa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754636Ab3A3Vmb convert rfc822-to-8bit (ORCPT
	<rfc822;kvm@vger.kernel.org>); Wed, 30 Jan 2013 16:42:31 -0500
Received: by mail-oa0-f48.google.com with SMTP id j1so968343oag.7
        for <kvm@vger.kernel.org>; Wed, 30 Jan 2013 13:42:31 -0800 (PST)
In-Reply-To: <1359580074.23274.32.camel@pasglop>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:

> On Wed, 2013-01-30 at 17:54 +0100, Andreas F=C3=A4rber wrote:
>>=20
>> 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-inheriten=
ce
>> due to arising complications, I thought. Wouldn't object if someone
>> wanted to do the dirty implementation work though. ;)
>>=20
>> 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 memo=
ry
> 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.