From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41417) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ugxfb-0005s1-0p for qemu-devel@nongnu.org; Mon, 27 May 2013 09:41:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UgxfV-0003bL-OQ for qemu-devel@nongnu.org; Mon, 27 May 2013 09:41:02 -0400 Received: from cantor2.suse.de ([195.135.220.15]:59404 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgxfV-0003ar-9G for qemu-devel@nongnu.org; Mon, 27 May 2013 09:40:57 -0400 Message-ID: <51A36264.6070002@suse.de> Date: Mon, 27 May 2013 15:40:52 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Selecting device variant types based on bdrv size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Kevin Wolf , Stefan Hajnoczi , "qemu-devel@nongnu.org Developers" , Markus Armbruster , Anthony Liguori , Jan Kiszka , "Edgar E. Iglesias" Hi, Am 27.05.2013 09:50, schrieb Peter Crosthwaite: > I have a bit of a chicken and egg problem trying to refactor Jans AT24 > I2C EEPROM model. I'm trying to migrate static class properties up to > the class level rather than down on the device property level (as we > did for EHCI in the sysbusification a while back). Problem is the > device model has part autodetection logic based on the size of the > backing image - you can instantiate the "abstract" class and selection > of what part it is depends on the backing file size. And so if we go > for one class for each separate part, we don't actually know what > concrete class to instantiate until we have a handle on the bdrv at > realize time which is way to late. Any Ideas? I think the practical question to ask is: What's the difference between those subclasses? Then maybe you can initialize YourAutoType::field from DerivedTypeClass::template_field or the like. I.e., the class is supposed to exist only once, so you can't modify it beyond class_init, but you can modify the instance including field values and per-instance callback hooks. For a vaguely related example, you may want to look at the history of target-ppc/kvm.c for how I previously mutated the host-ppc-cpu type - depending on the host, not user parameters (today it uses inheritance from a dynamically chosen base type instead; reason was not a technical one but that target-ppc/kvm.c does not get compile-tested on x86 if someone changes/adds ppc-cpu fields - no concern for regular devices). FWIW bdrv not fitting well into the realize scheme was the main reason behind going for DeviceState rather than Object for realize. ;) BTW do we have any guidance of when to use properties vs. subclasses? Might be a good addition to the QOMConventions page since it recently came up for CAN as well. > Can you safely change a devices type at realize time? >=20 > realize() { > ... > OBJECT(dev)->class =3D the_now_known_correct_child_class; > ... > } > > Obviously this would need an API call in QOM to sanity check it. Short answer: No, such a mutation is generally unsafe. Instance sizes can differ between types - could be sanity-checked. A type can expect to get access to its final class on instance_init. instance_init may init fields that you can only get by instantiating. A type mutation would change child<> or link<> properties at runtime. Realize will be too late to tweak the resulting instance further. Real OO languages don't support it, causing QOM lock-in. So I think this is rather hinting into the direction of a three-stage construction - instance_init, open, realize - as discussed by Kevin/Markus some time ago. Regards, 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