From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49194) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUf18-0002ez-Ps for qemu-devel@nongnu.org; Wed, 26 Aug 2015 14:01:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUf15-0006yB-JM for qemu-devel@nongnu.org; Wed, 26 Aug 2015 14:01:46 -0400 Received: from mail-qg0-x234.google.com ([2607:f8b0:400d:c04::234]:34264) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUf15-0006y7-F0 for qemu-devel@nongnu.org; Wed, 26 Aug 2015 14:01:43 -0400 Received: by qgeg42 with SMTP id g42so131857305qge.1 for ; Wed, 26 Aug 2015 11:01:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Programmingkid In-Reply-To: <20150826175359.GA4528@redhat.com> Date: Wed, 26 Aug 2015 14:01:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <29C62C49-06A5-4F99-8062-7269A28C29A3@gmail.com> <8737z7o85i.fsf@blackfin.pond.sub.org> <20150826172834.GQ21787@redhat.com> <20150826175359.GA4528@redhat.com> Subject: Re: [Qemu-devel] Should we auto-generate IDs? (was: [PATCH] qdev-monitor.c: Add device id generation) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Kevin Wolf , Jeff Cody , Markus Armbruster , qemu-devel qemu-devel , Paolo Bonzini , =?iso-8859-1?Q?Andreas_F=E4rber?= On Aug 26, 2015, at 1:53 PM, Daniel P. Berrange wrote: > On Wed, Aug 26, 2015 at 01:46:43PM -0400, Programmingkid wrote: >>=20 >> On Aug 26, 2015, at 1:28 PM, Daniel P. Berrange wrote: >>=20 >>> 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. >>>>=20 >>>> Relevant prior threads: >>>> * [PATCH] qdev: Reject duplicate and anti-social device IDs >>>> http://thread.gmane.org/gmane.comp.emulators.qemu/71230/focus=3D72272= >>>> * [PATCH 6/6] qdev: Generate IDs for anonymous devices >>>> = http://thread.gmane.org/gmane.comp.emulators.qemu/114853/focus=3D114858 >>>> * [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=3D300381 >>>>=20 >>>> Probably more I can't remember anymore :) >>>>=20 >>>> Programmingkid writes: >>>>=20 >>>>> Add device ID generation to each device if an ID isn't given. >>>>>=20 >>>>> Signed-off-by: John Arbuckle >>>>>=20 >>>>> --- >>>>> 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.=20 >>>>=20 >>>> The second sentence should really be part of your commit message. >>>> The first sentence wouldn't hurt, either. >>>>=20 >>>> Another useful addition would be *why* you want generated IDs. I >>>> believe you do because you need them for device_del. >>>>=20 >>>> In prior discussion, we always concluded that device_del should = accept >>>> QOM paths. It still doesn't. >>>>=20 >>>> Many things in QEMU have IDs. They all work pretty much the same: >>>>=20 >>>> 1. The ID is set by the user. If the user doesn't, there is none. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 2. The ID must be well-formed. >>>>=20 >>>> Exception: inconsistently enforced for QOM, see last thread quoted >>>> above. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>=20 >>> If QEMU auto-generates IDs, then the user still has to query QEMU to >>> figure out what ID was assigned. >>=20 >> Querying can be easy to do. Typing "info usb" in the monitor and=20 >> seeing the ID seems easy enough. The user can use the "device_del = " to >> remove the device. I made a patch for "info usb" to print the ID of = each >> usb device. >=20 > 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. >=20 >>> 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. >>=20 >> 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=20 >> 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. >=20 > 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?