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

[Programmingkid]

On Aug 26, 2015, at 1:53 PM, Daniel P. Berrange wrote:

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

What other problems did you have in mind?

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

I'm not following you. What do you mean by higher level mgmt layers?

Let me put it this way, if a user were to add a usb device to QEMU, say
a usb-mouse, but forgot to give it an ID. How do you expect that user to
remove the device from QEMU?