From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:46718)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1R4ITK-0001sS-7i
	for qemu-devel@nongnu.org; Thu, 15 Sep 2011 16:23:47 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1R4ITJ-0004lT-9U
	for qemu-devel@nongnu.org; Thu, 15 Sep 2011 16:23:46 -0400
Received: from mx1.redhat.com ([209.132.183.28]:25658)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1R4ITJ-0004lP-0f
	for qemu-devel@nongnu.org; Thu, 15 Sep 2011 16:23:45 -0400
Message-ID: <4E725EC9.6060506@redhat.com>
Date: Thu, 15 Sep 2011 23:23:37 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <4E70EC90.8000904@us.ibm.com> <4E719F7C.10700@redhat.com>
	<4E71FD19.6050606@codemonkey.ws>
In-Reply-To: <4E71FD19.6050606@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
List-Id: <qemu-devel.nongnu.org>
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>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Peter Maydell <peter.maydell@linaro.org>, Jan Kiszka <jan.kiszka@siemens.com>, qemu-devel <qemu-devel@nongnu.org>, Markus Armbruster <armbru@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, Paolo Bonzini <pbonzini@redhat.com>

On 09/15/2011 04:26 PM, Anthony Liguori wrote:
>
> I think this model is the closest to what we have today and is the 
> most obvious.  For something like ne2k, I would expect:
>
> class NE2000 : public Device
> {
>   // ne2k public functions
> };
>
> class PCI_NE2000 : public PciDevice
> {
>   // implement PCI functions by calling ne2k public functions
>   NE2000 ne2k;
> };
>
> class ISA_NE2000 : public IsaDevice
> {
>   // implement ISA functions by calling ne2k public functions
>   NE2000 ne2k;
> };

Also, NE2000 methods have to call ISA_NE2000 and PCI_NE2000 methods, 
yes?  That's going to be more difficult.  Not impossible, just hard.  
It's probably going to involve device specific code that models what 
type of glue was used for that particular device/bus combo.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.