From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnPFn-0004nb-0f for qemu-devel@nongnu.org; Mon, 02 Dec 2013 03:53:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VnPFg-0003EW-Sw for qemu-devel@nongnu.org; Mon, 02 Dec 2013 03:53:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnPFg-0003EM-Jq for qemu-devel@nongnu.org; Mon, 02 Dec 2013 03:53:12 -0500 Message-ID: <1385974376.2367.4.camel@localhost.localdomain> From: Marcel Apfelbaum Date: Mon, 02 Dec 2013 10:52:56 +0200 In-Reply-To: <529B526C.9020502@suse.de> References: <1385718225-26379-1-git-send-email-armbru@redhat.com> <1385903630.23603.7.camel@localhost.localdomain> <529B526C.9020502@suse.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/2] Pointer properties and device_add List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?ISO-8859-1?Q?F=E4rber?= Cc: peter.maydell@linaro.org, armbru@redhat.com, chouteau@adacore.com, qemu-devel@nongnu.org, blauwirbel@gmail.com, kraxel@redhat.com, aliguori@amazon.com, Paolo Bonzini , edgar.iglesias@gmail.com On Sun, 2013-12-01 at 16:14 +0100, Andreas F=C3=A4rber wrote: > Am 01.12.2013 14:13, schrieb Marcel Apfelbaum: > > On Fri, 2013-11-29 at 10:43 +0100, armbru@redhat.com wrote: > >> From: Markus Armbruster > >> > >> Pointer properties can be set only by code, not by device_add. A > >> device with a pointer property can't work with device_add only unles= s > >> the property may remain null. cannot_instantiate_with_device_add_ye= t > >> needs to be set then. PATCH 1/2 sets it when needed and else > >> documents why not. PATCH 2/2 documents this for future users of > >> pointer properties. > >> > >> This applies on top of my "[PATCH v4 00/10] Clean up and fix no_user= " > >> series. > >=20 > > Even that I am not familiar with this code, I've checked all the chan= ges > > and I agree with them. > >=20 > > Reviewed-by: Marcel Apfelbaum > >=20 > > Anyway, I do have a question: > > Why not asserting on qdev_device_add if we have a pointer property? >=20 > When we do device_add / device-add, the guest is usually running and we > shouldn't kill a running guest just because the user is trying somethin= g > stupid that we can easily prevent. ;) >=20 > The alternative BTW is dropping all those pointer properties and > replacing them with link<> properties. Paolo tried that for the OMAP > timers once but I fear that series was never picked up...? I heard about these link<> properties, can someone point me to their impl= ementation? >=20 > > Instead of checking only cannot_instantiate_with_device_add_yet, > > we can go over properties and if we have a pointer property, assert o= r > > return... >=20 > Raising an error for certain property types may be an option. Although > theoretically the existence of an incompatible property would not > necessarily indicate incompatibility to instantiate the device, in > practice I believe we don't have such excess properties. If a pointer property does not necessary mean: "Can't be used with device= _add", I am not so sure anymore... Thanks Andreas! Marcel >=20 > Regards, > Andreas >=20 > >=20 > > Thanks, > > Marcel > >=20 > >> > >> Markus Armbruster (2): > >> hw: cannot_instantiate_with_device_add_yet due to pointer props > >> qdev: Document that pointer properties kill device_add > >> > >> hw/audio/marvell_88w8618.c | 2 ++ > >> hw/dma/sparc32_dma.c | 2 ++ > >> hw/gpio/omap_gpio.c | 4 ++++ > >> hw/i2c/omap_i2c.c | 2 ++ > >> hw/i2c/smbus_eeprom.c | 2 ++ > >> hw/intc/etraxfs_pic.c | 4 ++++ > >> hw/intc/grlib_irqmp.c | 2 ++ > >> hw/intc/omap_intc.c | 4 ++++ > >> hw/net/etraxfs_eth.c | 2 ++ > >> hw/net/lance.c | 2 ++ > >> include/hw/qdev-properties.h | 17 +++++++++++++++++ > >> 11 files changed, 43 insertions(+) > >> > >=20 > >=20 > >=20 >=20 >=20