From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCTgz-0005cx-EZ for qemu-devel@nongnu.org; Tue, 27 Mar 2012 06:31:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCTgt-0000ca-1w for qemu-devel@nongnu.org; Tue, 27 Mar 2012 06:31:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCTgs-0000cH-QM for qemu-devel@nongnu.org; Tue, 27 Mar 2012 06:31:50 -0400 Message-ID: <4F71970D.7060802@redhat.com> Date: Tue, 27 Mar 2012 12:31:41 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1332727608-26523-1-git-send-email-liwp@linux.vnet.ibm.com> <4F705F08.4010002@siemens.com> <20120326155444.GJ6016@valinux.co.jp> <4F70A77D.3020204@codemonkey.ws> In-Reply-To: <4F70A77D.3020204@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Anthony Liguori , Wanpeng Li , Jan Kiszka , qemu-devel@nongnu.org, Isaku Yamahata , Paolo Bonzini , Gavin Shan On 03/26/2012 07:29 PM, Anthony Liguori wrote: > On 03/26/2012 10:54 AM, Isaku Yamahata wrote: >> On Mon, Mar 26, 2012 at 02:20:24PM +0200, Jan Kiszka wrote: >>> I'm also sure we will have to refactor the merge significantly again >>> for >>> the introduction of additional chipsets and PC boards. But unless those >>> requirements can already be specified (Isaku?), that might be >>> unavoidable. >> >> Agreed. At least I'd like pam/smram stuff decoupled from piix. > > s/piix/i440fx/ > > PAM/SRAM has nothing do to with the piix. Part of the problem with > the current layout is that the distinction between i440fx and piix is > not clear. The piix is just a SuperIO chip (and southbridge). Right. > > I think the better approach is to have a PCNorthBridge base-class that > contains functionality like PAM/SRAM that both I440FX and Q35 inherit > from. I hate to transform this into a languagey discussion, but I don't think inheritance is the right thing here. While both 440fx and q35 are north bridges, the similar implementation of PAM/SMRAM is not part of that. It's just a random result of the chips' evolution. I think the code for PAM/SMRAM can be reused if the specs match, but using a has-a instead of an is-a relationship. As a counterexample, consider a northbridge that implements PAM/SMRAM differently. You'd have to refactor PCNorthBridge into two separate classes. With the other approach the new northbridge simply doesn't include the existing PAM/SMRAM implementation and instead implements its own. -- error compiling committee.c: too many arguments to function