From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJoVk-0007Kz-By for qemu-devel@nongnu.org; Thu, 04 Oct 2012 12:43:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJnqi-0005al-CU for qemu-devel@nongnu.org; Thu, 04 Oct 2012 12:01:24 -0400 Received: from cantor2.suse.de ([195.135.220.15]:43186 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJnqi-0005Xm-07 for qemu-devel@nongnu.org; Thu, 04 Oct 2012 12:00:32 -0400 Message-ID: <506DB297.8060509@suse.de> Date: Thu, 04 Oct 2012 18:00:23 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1349270954-4657-1-git-send-email-ehabkost@redhat.com> <1349270954-4657-2-git-send-email-ehabkost@redhat.com> <877gr6jqnt.fsf@codemonkey.ws> <506D940D.7080600@redhat.com> In-Reply-To: <506D940D.7080600@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Igor Mammedov , Gleb Natapov , Eduardo Habkost , Anthony Liguori , qemu-devel@nongnu.org Am 04.10.2012 15:50, schrieb Paolo Bonzini: > Il 04/10/2012 15:46, Anthony Liguori ha scritto: >>>> +typedef struct PC { >>>> + DeviceState parent_obj; >>>> +} PC; >> So the general problem with this approach is that it strays from >> modeling hardware. >=20 > It doesn't really; it's a motherboard object, there's no reason why > /machine shouldn't be a Device itself, with a few objects (CPUs, the > i440FX, the IOAPIC, and of course the peripherals) hanging off it. On the other hand, why should it? We'd have QEMUMachine::reset vs. DeviceState::reset then and I don't see an immanent need for gpio / irqs on the mainboard either (on evaluation boards there are, but they are usually properties of the SoC modelling-wise). If we want to bundle objects, we have a dedicated Container type; otherwise we could just derive from TYPE_OBJECT directly. In the end it just goes back to our attempt to generalize the properties mechanisms and/or to a lack of APIs to do exactly what we want... ;) Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg