From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60487) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUy1s-0004yR-FT for qemu-devel@nongnu.org; Thu, 27 Aug 2015 10:19:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUy1n-0000ho-JL for qemu-devel@nongnu.org; Thu, 27 Aug 2015 10:19:48 -0400 Received: from mail-qk0-x234.google.com ([2607:f8b0:400d:c09::234]:33598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUy1n-0000hg-FC for qemu-devel@nongnu.org; Thu, 27 Aug 2015 10:19:43 -0400 Received: by qkch123 with SMTP id h123so11152490qkc.0 for ; Thu, 27 Aug 2015 07:19:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Programmingkid In-Reply-To: <55DF1828.4000904@redhat.com> Date: Thu, 27 Aug 2015 10:19:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <31930DF5-9425-4902-BF33-CA6CC498DC90@gmail.com> References: <87fv36j9j6.fsf@blackfin.pond.sub.org> <20150826172550.GJ11016@localhost.localdomain> <20150826180815.GK11016@localhost.localdomain> <20150826220151.GA2669@localhost.localdomain> <2CB0CE30-A638-4933-A1D6-F65CA4910E61@gmail.com> <20150827123234.GB2669@localhost.localdomain> <55DF09DB.2000406@redhat.com> <221424A1-B3AA-4746-BAF3-BEBCC1CA73DC@gmail.com> <20150827135120.GT24486@redhat.com> <55DF1828.4000904@redhat.com> Subject: Re: [Qemu-devel] Should we auto-generate IDs? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , Jeff Cody , Markus Armbruster , qemu-devel qemu-devel , Paolo Bonzini , jsnow@redhat.com, =?iso-8859-1?Q?Andreas_F=E4rber?= On Aug 27, 2015, at 10:01 AM, Eric Blake wrote: > On 08/27/2015 07:51 AM, Daniel P. Berrange wrote: >> On Thu, Aug 27, 2015 at 09:39:10AM -0400, Programmingkid wrote: >>>=20 >>>> Better still might be fixing things to where we add a global = command >>>> line option that outright fails any attempt to create an unnamed = object. >>>> The option would be off by default for back-compat. But management >>>> apps like libvirt can turn it on once they are prepared to name = every >>>> object they create (which in turn may imply fixing any remaining >>>> interfaces that cannot name an object to add in that ability for >>>> management to pass in a name). Then there would be no unnamed = objects, >>>> no ambiguity, and no need to generate names. >>>=20 >>> I do agree with giving every device an ID, but I don't think failing = if the user >>> forgets to give one is necessary. If libvirt doesn't give devices = and ID, it >>> would probably benefit from having QEMU do it for libvirt. >=20 > No, you're misunderstanding our argument. The moment there is more = than > one device with an auto-assigned name is the moment that management > doesn't know which device got which name, so it's better for = management > to pick a name in the first place. Ok. I see. You might be assuming that QEMU will be the only one to give = a device an ID. The ID will ONLY be given if the user or libvirt *doesn't* give = it. So libvirt would be able to function just fine with an ID generating system.=20 >>=20 >> Libvirt always gives an explicit ID. >=20 > Except it doesn't, yet. Libvirt still needs to be taught to name all > node devices (and I'm slowly trying to work on patches towards that = goal). Well if Libvirt doesn't give an ID to a device, then it won't be able to = use monitor commands that depend on the ID. This sounds like a completely different = problem. >=20 >> It is impossible to rely on QEMU >> assigning IDs, because there is no reliable way to identify what ID >> QEMU assigned to each device after the fact. Other management apps >> would have the same problem, so auto-generated IDs are pretty useless >> in that respect. >=20 > It's not to say that auto-generated names would be useless when = running > qemu manually from the command line, but I agree that management > probably can't safely rely on auto-generated names, and therefore > solving the issue of auto-generating names is less important. What if we change this so that management applications could actually = query devices and their properties. I'm thinking some kind of JSON-like = output. Something like 'info all-devices'. It prints the device name, location, = and ID. This list should be easy to parse by Libvirt.=20