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

[Daniel P. Berrange]

On Wed, Aug 26, 2015 at 01:46:43PM -0400, Programmingkid wrote:
> 
> On Aug 26, 2015, at 1:28 PM, Daniel P. Berrange wrote:
> 
> > On Tue, Aug 25, 2015 at 02:38:17PM +0200, Markus Armbruster wrote:
> >> 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.
> > 
> > If QEMU auto-generates IDs, then the user still has to query QEMU to
> > figure out what ID was assigned.
> 
> Querying can be easy to do. Typing "info usb" in the monitor and 
> seeing the ID seems easy enough. The user can use the "device_del <id>" to
> remove the device. I made a patch for "info usb" to print the ID of each
> usb device.

That only works if you look 'info usb' after adding each device. If
you added multiple devices and then try to identify the ID after the
fact it is not guaranteed unambiguous. Using 'info usb' is also not
a general solution to the problem for other types of device.

> > If the device was not assigned an
> > ID, then it surely becomes hard for the user to identify which device
> > they just added in order to ask what its ID is. Which is a chicken
> > and egg problem. Even if the user could figure out what device they
> > just added, why go to the extra trouble of querying QEMU to find out
> > the auto-generated ID, when you could just provide an ID explicitly
> > upfront avoiding the entire problem. IMHO auto-generating IDs is a
> > just road to nowhere. Ideally we would mandate user provided IDs
> > but we sadly can't for back-compat reasons.
> 
> Auto-generated ID's can be a good thing. If the user adds a usb device
> to QEMU, but forgot to give it an ID, QEMU can be nice enough to do it for
> that user. This feature would make the monitor command device_del
> actually useful in this situation. Right now if the user forgets to give a 
> device an ID, that user is out of luck when it comes time to removing
> the device. This device id generation feature makes QEMU more
> robust.

If a user is talking to the QEMU monitor directly there are plenty of ways
to go wrong, of which forgetting to provide an ID is a really minor one.
That's why it is generally left to higher level mgmt layers to talk to
QEMU and deal with all the issues in this area. IOW if users are talking
to the monitor directly, IMHO they've already lost.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|