[Qemu-devel] Should we auto-generate IDs? (was: [PATCH] qdev-monitor.c: Add device id generation)

[Markus Armbruster]

You're proposing to revise a qdev design decision, namely the purpose of
IDs.  This has been discussed before, and IDs remained unchanged.
Perhaps it's time to revisit this issue.  Cc'ing a few more people.

Relevant prior threads:
* [PATCH] qdev: Reject duplicate and anti-social device IDs
  http://thread.gmane.org/gmane.comp.emulators.qemu/71230/focus=72272
* [PATCH 6/6] qdev: Generate IDs for anonymous devices
  http://thread.gmane.org/gmane.comp.emulators.qemu/114853/focus=114858
* [PATCH] qdev: Assign a default device ID when none is provided.
  http://thread.gmane.org/gmane.comp.emulators.qemu/249702
* IDs in QOM (was: [PATCH] util: Emancipate id_wellformed() from QemuOpt
  http://thread.gmane.org/gmane.comp.emulators.qemu/299945/focus=300381

Probably more I can't remember anymore :)

Programmingkid <address@hidden> writes:

> Add device ID generation to each device if an ID isn't given.
>
> Signed-off-by: John Arbuckle <address@hidden>
>
> ---
> This patch can be tested by adding adding usb devices using the monitor.
> Start QEMU with the -usb option. Then go to the monitor and type
> "device_add usb-mouse". The ID of the device will be set to a number.
> Since QEMU will not allow an user to add a device with an ID set to a
> number, there is no chance for ID collisions. 

The second sentence should really be part of your commit message.
The first sentence wouldn't hurt, either.

Another useful addition would be *why* you want generated IDs.  I
believe you do because you need them for device_del.

In prior discussion, we always concluded that device_del should accept
QOM paths.  It still doesn't.

Many things in QEMU have IDs.  They all work pretty much the same:

1. The ID is set by the user.  If the user doesn't, there is none.

   Exception: a few old interfaces set well-known IDs.  If the user uses
   these interfaces, he needs to take care that his own IDs don't clash.

   Example: drive_add picks an ID based on interface type, media type,
   bus and unit number.  blockdev_add doesn't.  Instead, it requires the
   user to pick one.

2. The ID must be well-formed.

   Exception: inconsistently enforced for QOM, see last thread quoted
   above.

3. If the user may need to address the thing, either the ID must be
   mandatory, or there has to be another way to address it.

   Example: netdev-add requires ID.  Rationale: the only way to put it
   to use is referencing it from a device, and that requires an ID.

   Example: device_add doesn't require ID.  If you don't specify one,
   you can't device_del it.  Annoying trap for the unwary.  There are
   *two* other ways to address it: qdev path and QOM path.  qdev path is
   basically too botched to be usable.  QOM path should do just fine,
   but device_del doesn't accept it.  It could.

We could revise rule 1 to always generate IDs, in a way that can't clash
with the user's IDs (impossible unless rule 2 is actually observed).
Rule 3 then becomes moot.

Whatever we do, I want it done consistently.  I don't want different
rules for different kinds of IDs.