qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 14/16] qapi: deprecate "device" field of DEVICE_* events


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH v4 14/16] qapi: deprecate "device" field of DEVICE_* events
Date: Tue, 14 Feb 2023 12:53:01 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.7.2

On 14/2/23 12:49, Markus Armbruster wrote:
Daniel P. Berrangé <berrange@redhat.com> writes:

On Tue, Feb 14, 2023 at 10:25:22AM +0100, Peter Krempa wrote:
On Tue, Feb 14, 2023 at 09:54:22 +0100, Markus Armbruster wrote:
Daniel P. Berrangé <berrange@redhat.com> writes:

On Mon, Feb 13, 2023 at 05:01:01PM +0300, Vladimir Sementsov-Ogievskiy wrote:
The device field is redundant, because QOM path always include device
ID when this ID exist.

The flipside to that view is that applications configuring QEMU are
specifying the device ID for -device (CLI) / device_add (QMP) and
not the QOM path. IOW, the device ID is the more interesting field
than QOM path, so feels like the wrong one to be dropping.

QOM path is a reliable way to identify a device.  Device ID isn't:
devices need not have one.  Therefore, dropping the QOM path would be
wrong.

Is there any real benefit to dropping this ?

The device ID is a trap for the unwary: relying on it is fine until you
run into a scenario where you have to deal with devices lacking IDs.

Note that libvirt's code is still using the 'device' bit rather than QOM
path and the fix might not be entirely trivial although should not be
too hard.

What's the documented way to construct a QOM path, given only an ID  as
input ?

QOM paths a gap in our documentation, even though the composition tree
structure has been stable since day one, and is de facto ABI.

Short answer: "/machine/peripheral/ID".

Long answer follows.

We have three "containers" under /machine that serve as parents for
devices:

* /machine/peripheral/

   Parent of user-created devices with ID.  Children are named "ID".

   Put there by qdev_set_id(), called from qdev_device_add_from_qdict().

   On "user-created": Nothing stops board code to abuse qdev_set_id() for
   onboard devices, directly or indirectly, but it really, really
   shouldn't.

* /machine/peripheral-anon/

   Parent of user-created devices without ID.  Children are named
   "device[N]", where N counts up from zero.

   Put there by qdev_set_id(), called from qdev_device_add_from_qdict().

   Again, abuse by board code is possible, but would be wrong.

   Beware: a particular device's N changes when the set of devices
   created before it grows or shrinks.  Messing with the machine type can
   change it (different onboard devices).

* /machine/unattached/

   Surrogate parent of onboard devices created without a parent.

   Put there by device_set_realized() (general case),
   qdev_connect_gpio_out_named() (input pins) , memory_region_do_init()
   (memory regions), qemu_create_machine() (the main sysbus).

   I believe this container was created as a convenience, so we don't
   have to retrofit parents to existing code.  Probably abused ever
   since.

Are you suggesting this is a stable interface and we can not move
devices (like from /machine/unattached/ to /machine/peripheral/)
without going thru the deprecation process?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]