From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:60579)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Paul_Brook@mentor.com>) id 1SA1aI-00042D-Fi
	for qemu-devel@nongnu.org; Tue, 20 Mar 2012 12:07:00 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <Paul_Brook@mentor.com>) id 1SA1aC-0002cc-7k
	for qemu-devel@nongnu.org; Tue, 20 Mar 2012 12:06:54 -0400
Received: from relay1.mentorg.com ([192.94.38.131]:40612)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Paul_Brook@mentor.com>) id 1SA1aC-0002cS-1i
	for qemu-devel@nongnu.org; Tue, 20 Mar 2012 12:06:48 -0400
From: Paul Brook <paul@codesourcery.com>
Date: Tue, 20 Mar 2012 16:06:41 +0000
References: <CAFEAcA_PZ-ZdbhFCWw=oHzPLNJWdx4fKA-qaHxLmuW1pwDNq9w@mail.gmail.com>
	<201203201408.56275.paul@codesourcery.com>
	<CAFEAcA9XBoM0AMxv+V+gDX+pWTU5hku-5+ytmXt9X+Zq+B2JEA@mail.gmail.com>
In-Reply-To: <CAFEAcA9XBoM0AMxv+V+gDX+pWTU5hku-5+ytmXt9X+Zq+B2JEA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201203201606.42031.paul@codesourcery.com>
Subject: Re: [Qemu-devel] ARM QOM conversion / class hierarchy
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: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>, Anthony Liguori <anthony@codemonkey.ws>, Andreas =?utf-8?q?F=C3=A4rber?= <afaerber@suse.de>

> > If we're going to use the class hierachy to implement functionality then
> > there are other candidates.  Given the primary purpose of QOM is [IMO]
> > to handle interaction between devices, the external interface exposed by
> > the core seems like a better candidate for subclassing.  i.e.
> > conventional ARM cores with IRQ and FIQ inputs[1] v.s. M profile devices
> > where the core exception model is intimately tied to the interrupt
> > controller.
> 
> Yes, I think I'd agree there. So should we just have an init function
> that provides the implementation-specific cp15 registers based on the value
> provided in the QOM property for the main ID register?

Something like that, yes.  I'm not convinced the main ID register is the right 
property to use, but for actual implementation specific bits (rather than bits 
where an implementation picks one of a few common options) I guess we don't 
have any alternative but enumerating the implementations we support.

Paul