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 <programmingk...@gmail.com> writes: >>>> >>>>> Add device ID generation to each device if an ID isn't given. >>>>> >>>>> Signed-off-by: John Arbuckle <programmingk...@gmail.com> >>>>> >>>>> --- >>>>> 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?