From mboxrd@z Thu Jan  1 00:00:00 1970
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: KVM call minutes 2013-01-29 - Port I/O
Date: Thu, 31 Jan 2013 08:07:54 +1100
Message-ID: <1359580074.23274.32.camel@pasglop>
References: <871ud4gfoa.fsf@elfo.elfo> <5109065B.4060803@suse.de>
	<51094024.20803@redhat.com> <87vcae8wbk.fsf@codemonkey.ws>
	<51095049.7090407@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: KVM devel mailing list <kvm@vger.kernel.org>,
	Juan Quintela <quintela@redhat.com>, "Michael S.
	Tsirkin" <mst@redhat.com>, qemu-devel <qemu-devel@nongnu.org>,
	Alexander Graf <agraf@suse.de>, qemu-ppc <qemu-ppc@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	=?ISO-8859-1?Q?Herv=E9?= Poussineau <hpoussin@reactos.org>,
	Alon Levy <alevy@redhat.com>, David Gibson <david@gibson.dropbear.id.au>
To: Andreas =?ISO-8859-1?Q?F=E4rber?= <afaerber@suse.de>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <51095049.7090407@suse.de>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
List-Id: kvm.vger.kernel.org

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-inheritence
> 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 memory
serves me well).

Cheers,
Ben.