From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SA4M0-0003p5-Ah for qemu-devel@nongnu.org; Tue, 20 Mar 2012 15:04:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SA4Ly-0007Fi-Eb for qemu-devel@nongnu.org; Tue, 20 Mar 2012 15:04:19 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:39071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SA4Ly-0007FS-8B for qemu-devel@nongnu.org; Tue, 20 Mar 2012 15:04:18 -0400 Received: by yhoo21 with SMTP id o21so478337yho.4 for ; Tue, 20 Mar 2012 12:04:16 -0700 (PDT) Sender: fluxion Date: Tue, 20 Mar 2012 14:04:11 -0500 From: Michael Roth Message-ID: <20120320190411.GC29058@illuin> References: <20120320163120.GB29058@illuin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] ARM QOM conversion / class hierarchy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Paul Brook , QEMU Developers , Anthony Liguori , Andreas =?iso-8859-1?Q?F=E4rber?= On Tue, Mar 20, 2012 at 04:32:31PM +0000, Peter Maydell wrote: > On 20 March 2012 16:31, Michael Roth wrote: > > Rather than key off an ID you could also just break > > implementation-specific functionality out into a set of interfaces you > > implement/override as part of the objects' initialization. Same ends, and > > still fits the model pretty nicely, assuming the functionality is all > > derivable from the common base-class. > > I'm not sure what you have in mind here -- could you explain > in a little more detail, please? Essentially what Paul suggested, minimal subclassing to encapsulate the major architectural characteristics of a cpu, but also making use of the fact that we *do* have multiple inheritance for QOM interfaces to do finer-grained modeling of specific features. SIMD/NEON/DSP, for instance, could be proper QOM interfaces that models from multiple families/architectures implement. Ultimately, as Paul said, it just boils down to implicit subclasses in place of enumerating features for use by common routines. So..it doesn't buy you much really, except maybe maintaining devices out of tree. But it's a way to do what you were suggesting with option #2 while avoiding not being "OO-like", since it's a more formal way to modify a class' behavior. But maybe that's a non-issue to begin with. > > thanks > -- PMM >