On 14.02.23 14:57, Markus Armbruster wrote:
Daniel P. Berrangé <berrange@xxxxxxxxxx> writes:
On Tue, Feb 14, 2023 at 09:54:22AM +0100, Markus Armbruster wrote:
Daniel P. Berrangé <berrange@xxxxxxxxxx> 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.
When a mgmt app is configuring QEMU though, it does it exclusively
with device ID values. If I add a device "-device foo,id=dev0",
and then later hot-unplug it "device_del dev0", it is pretty
reasonable to then expect that the DEVICE_DELETED even will then
include the ID value the app has been using elsewhere.
The management application would be well advised to use QOM paths with
device_del, because only that works even for devices created by default
(which have no ID), and devices the user created behind the management
application's back.
If the mgmt app is using IDs everywhere when dealing with a device,
then trap effectively doesn't exist for their usage scenario.
What if we go one step further and deprecate "id" in device_add / device_del as well?
So that user will have to use qom path also in device_add. We may return an error if user don't specify "machine/peripheral/" prefix.. Or allow to create device with any QOM path?
--
Best regards,
Vladimir
