From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH kvm-unit-tests 2/4] Introduce a C++ wrapper for the kvm APIs Date: Wed, 24 Nov 2010 11:14:41 -0600 Message-ID: <4CED4801.8040300@codemonkey.ws> References: <20101124154006.GE15111@redhat.com> <4CED344B.3030000@codemonkey.ws> <20101124161204.GF15111@redhat.com> <4CED39DE.3030207@redhat.com> <20101124162153.GA20014@redhat.com> <4CED3C88.3040501@redhat.com> <20101124162956.GB20014@redhat.com> <4CED3E4D.8050608@redhat.com> <20101124165244.GD20014@redhat.com> <4CED43D4.1070107@redhat.com> <20101124170209.GF20014@redhat.com> <4CED463F.7080700@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , Alexander Graf , Marcelo Tosatti , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mail-gy0-f174.google.com ([209.85.160.174]:51368 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750868Ab0KXRPP (ORCPT ); Wed, 24 Nov 2010 12:15:15 -0500 Received: by gyb11 with SMTP id 11so2906272gyb.19 for ; Wed, 24 Nov 2010 09:15:14 -0800 (PST) In-Reply-To: <4CED463F.7080700@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/24/2010 11:07 AM, Avi Kivity wrote: > On 11/24/2010 07:02 PM, Gleb Natapov wrote: >> On Wed, Nov 24, 2010 at 06:56:52PM +0200, Avi Kivity wrote: >> > On 11/24/2010 06:52 PM, Gleb Natapov wrote: >> > >> Plus some magic glue. You can't say it is an ISA bridge. It's >> > >> exactly what its spec says it is. >> > >> >> > >First thing my spec says is "Bridge Between the PCI Bus and ISA Bus" >> > >> > It's the first item in a list of features. Be serious. >> > >> I am serious. The fact that it provides IDE or kbd doesn't make this IDE >> or kbd special. It means that it has gates that provide functionality of >> those chips. Just like SoC really. IDE doesn't become part of ARM cpu >> just because some SoC somewhere include them on the same silicon. > > They aren't special. They're just part of the PIIX3 device. So based on the IRC discussion that pbrook and I have been having, you can think of things like this: class PIIX3 { public: Plug i8042; }; A plug allows conditional composition whereas the absence of a plug means unconditional composition. There is a mechanism to name plugs and you can have an i8042 factory to create the device and then conditionally attach it to the plug. This is fine even though I think it's unnecessary abstraction. What I object to is introducing an artificial ISA bus layering. A Plug is basically a Type * except it has some additional features. It provides null-pointer dereference checking, provides a marshalling interface, and supports the ability to be locked which enables a device to enforce that plugging cannot happen after the device is realized (power-on). >> > When we do have a spec for something, we should implement it as the >> > spec says, not according to our ideas of how it should be. >> > >> PIIX3 is composite device. It is not one device. To emulate it you need >> to provide functionality of all devices included om PIIX3. Spec says >> nothing about how it should be implemented. > > Right, we could (and probably should) implement it as > > class PIIX3 { > private: > class isa_bridge { .... }; > isa_bridge isa_bridge; No, PIIX3 is an PCI-to-ISA bridge. It's a fundamental part of the definition of it as a PCI device. Regards, Anthony Liguori > i8042 kbc; > ... > } > > So the thing becomes just a glue layer for various components. But > when pc.c says PIIX3, it gets what the spec says, not something else. >