All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Marcel Apfelbaum <marcel.a@redhat.com>, armbru@redhat.com
Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org,
	chouteau@adacore.com, blauwirbel@gmail.com, kraxel@redhat.com,
	aliguori@amazon.com, Paolo Bonzini <pbonzini@redhat.com>,
	edgar.iglesias@gmail.com
Subject: Re: [Qemu-devel] [PATCH 0/2] Pointer properties and device_add
Date: Sun, 01 Dec 2013 16:14:52 +0100	[thread overview]
Message-ID: <529B526C.9020502@suse.de> (raw)
In-Reply-To: <1385903630.23603.7.camel@localhost.localdomain>

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 <armbru@redhat.com>
>>
>> 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 unless
>> the property may remain null.  cannot_instantiate_with_device_add_yet
>> 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.
> 
> Even that I am not familiar with this code, I've checked all the changes
> and I agree with them.
> 
> Reviewed-by: Marcel Apfelbaum <marcel.a@redhat.com>
> 
> Anyway, I do have a question:
> Why not asserting on qdev_device_add if we have a pointer property?

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 something
stupid that we can easily prevent. ;)

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...?

> Instead of checking only cannot_instantiate_with_device_add_yet,
> we can go over properties and if we have a pointer property, assert or
> return...

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.

Regards,
Andreas

> 
> Thanks,
> Marcel
> 
>>
>> 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(+)
>>
> 
> 
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

  reply	other threads:[~2013-12-01 15:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-29  9:43 [Qemu-devel] [PATCH 0/2] Pointer properties and device_add armbru
2013-11-29  9:43 ` [Qemu-devel] [PATCH 1/2] hw: cannot_instantiate_with_device_add_yet due to pointer props armbru
2013-11-29 10:23   ` Edgar E. Iglesias
2013-12-15 20:55   ` Andreas Färber
2013-12-15 21:10     ` Peter Maydell
2013-12-16  8:48       ` Markus Armbruster
2013-12-16  9:33         ` Peter Maydell
2013-12-16 11:17           ` Markus Armbruster
2014-01-07 12:33           ` Andreas Färber
2014-01-07 12:43             ` Peter Maydell
2014-01-07 13:04               ` Andreas Färber
2014-01-07 13:05               ` Peter Crosthwaite
2014-01-10  9:10                 ` Andreas Färber
2014-01-10 10:35                   ` Peter Crosthwaite
2014-01-07 14:08               ` Markus Armbruster
2014-01-07 16:50               ` Paolo Bonzini
2013-11-29  9:43 ` [Qemu-devel] [PATCH 2/2] qdev: Document that pointer properties kill device_add armbru
2013-12-01 13:13 ` [Qemu-devel] [PATCH 0/2] Pointer properties and device_add Marcel Apfelbaum
2013-12-01 15:14   ` Andreas Färber [this message]
2013-12-02  7:30     ` Markus Armbruster
2013-12-02  9:05       ` Marcel Apfelbaum
2013-12-02  8:52     ` Marcel Apfelbaum
2013-12-15 20:51       ` Andreas Färber
2013-12-16  8:26         ` Marcel Apfelbaum
2013-12-15 21:02 ` Andreas Färber
2013-12-16  8:52   ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=529B526C.9020502@suse.de \
    --to=afaerber@suse.de \
    --cc=aliguori@amazon.com \
    --cc=armbru@redhat.com \
    --cc=blauwirbel@gmail.com \
    --cc=chouteau@adacore.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=kraxel@redhat.com \
    --cc=marcel.a@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.