From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51798) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7Lbq-0002fH-45 for Qemu-devel@nongnu.org; Tue, 23 Jun 2015 06:39:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7Lbm-0002ih-Qb for Qemu-devel@nongnu.org; Tue, 23 Jun 2015 06:39:18 -0400 Received: from cantor2.suse.de ([195.135.220.15]:40004 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7Lbm-0002i8-KQ for Qemu-devel@nongnu.org; Tue, 23 Jun 2015 06:39:14 -0400 Message-ID: <55893750.3020502@suse.de> Date: Tue, 23 Jun 2015 12:39:12 +0200 From: =?windows-1252?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <803004FB-2F23-439C-AF59-E71FA7DDC2C4@livius.net> In-Reply-To: <803004FB-2F23-439C-AF59-E71FA7DDC2C4@livius.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] QDev explicit constructors & destructors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Liviu Ionescu , QEMU Developers Cc: Paolo Bonzini , Peter Crosthwaite Hi Liviu, Am 15.06.2015 um 15:35 schrieb Liviu Ionescu: >> On 15 Jun 2015, at 13:48, Liviu Ionescu wrote: >> >> ... One natural solution would be to add an explicit constructor, like= in C++.=20 >=20 > if this solution is considered too complicated, it might also be possib= le to arrange for the constructor data to be passed to the existing .inst= ance_init call. >=20 > the use case would be even simpler: >=20 > DeviceState *mcu =3D qdev_create_with_data(NULL, TYPE_STM32F103RB, &c= onstructor_data); > { > /* Set various properties. */ > qdev_prop_set_uint32(mcu, "hse-freq-hz", 8000000); /* 8.0 MHz */ > qdev_prop_set_uint32(mcu, "lse-freq-hz", 32768); /* 32 KHz */ > } These {...} blocks have no justification at all, so please avoid them for the sake of readability. Just use empty lines for grouping, that spares indentation. > qdev_realize(mcu); /* QDev specific step */ [snip] Please don't add new infrastructure with "qdev" in the name, qdev was the old device infrastructure that has been replaced with QOM; use "device" naming for any new APIs. But really, you should read up on the two discussions, a) when Anthony introduced QOM (several looong threads with Paolo, Avi and others) and b) when I ran into the issue of virtual methods (start with the resulting documentation in object.h). You seem to be opening a can of worms without understanding where we're coming from, how it's being used and where this is headed: QOM is not just a random C++-in-C framework. We've specifically banned pointers except for a handful by converting to link<> properties, and I see adding random opaque pointers to the generic constructor model - be it for devices or all objects - as a clear no-no. Look at how QOM objects are being instantiated from QMP commands or config files as a hint to what you're missing here (apart from CC'ing the right maintainers ;)). (Note that quite similarly Linux has been replacing platform data structs with Device Tree nodes.) If you do in some local case want to pass local C data to the object, you can already do so via .class_data if all instances are the same, as in your case of a single MCU on a board probably. If I'm not seeing the problem, you'll need to explain better why class_init + instance_init + properties + realize doesn't fit your use ca= se. That said, your efforts of simplifying STM32 instantiation are appreciated. I've been wanting to add an F429 Discovery machine for my Linux port. Cheers, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N=FCrnberg)