From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40343) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUzZN-0005PH-0r for qemu-devel@nongnu.org; Thu, 27 Aug 2015 11:58:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUzZI-00023k-VV for qemu-devel@nongnu.org; Thu, 27 Aug 2015 11:58:28 -0400 Received: from mail-qg0-x229.google.com ([2607:f8b0:400d:c04::229]:34137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUzZI-00022o-PJ for qemu-devel@nongnu.org; Thu, 27 Aug 2015 11:58:24 -0400 Received: by qgeg42 with SMTP id g42so13320854qge.1 for ; Thu, 27 Aug 2015 08:58:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Programmingkid In-Reply-To: <20150827154057.GE2669@localhost.localdomain> Date: Thu, 27 Aug 2015 11:58:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <068B4976-968C-45A3-9219-77FB600BC257@gmail.com> References: <20150826220151.GA2669@localhost.localdomain> <2CB0CE30-A638-4933-A1D6-F65CA4910E61@gmail.com> <20150827123234.GB2669@localhost.localdomain> <56530C98-D6B3-417E-BB58-E29412283BF1@gmail.com> <20150827134943.GS24486@redhat.com> <37557843-A1BA-4822-9933-B0B8AD588C90@gmail.com> <55DF1884.2030608@redhat.com> <20150827144253.GX24486@redhat.com> <20150827154057.GE2669@localhost.localdomain> Subject: Re: [Qemu-devel] Should we auto-generate IDs? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody Cc: Kevin Wolf , jsnow@redhat.com, Markus Armbruster , qemu-devel qemu-devel , Paolo Bonzini , =?iso-8859-1?Q?Andreas_F=E4rber?= On Aug 27, 2015, at 11:40 AM, Jeff Cody wrote: > On Thu, Aug 27, 2015 at 11:20:20AM -0400, Programmingkid wrote: >>=20 >> On Aug 27, 2015, at 10:42 AM, Daniel P. Berrange wrote: >>=20 >>> On Thu, Aug 27, 2015 at 10:34:05AM -0400, Programmingkid wrote: >>>>=20 >>>> On Aug 27, 2015, at 10:02 AM, Eric Blake wrote: >>>>=20 >>>>> On 08/27/2015 07:56 AM, Programmingkid wrote: >>>>>=20 >>>>>>> If we did have auto-generated names, we would need to come up = with a >>>>>>> scheme that is not going to clash with any existing naming that = users >>>>>>> of QEMU may already be doing, otherwise we risk causing a = regression. >>>>>>> Something as simple as what you suggest has non-trivial chance = of >>>>>>> clashing. >>>>>>=20 >>>>>> Actually there is a way to prevent clashing. When QEMU = auto-generates a >>>>>> name, it could scan all the ID's to see if there is a clash. If = the ID is already >>>>>> taken, just increment the ID until it is detected to be unique. = The previous >>>>>> threads on this subject has patches that did just that. This = means that a >>>>>> ID scheme that is just a single number would work without = clashes.=20 >>>>>=20 >>>>> No, because you cannot predict what FUTURE names the user will = request. >>>>> The name generated by qemu must be IMPOSSIBLE to request manually, = and >>>>> not just one that happens not to clash at the current moment. >>>>=20 >>>> If I add a device with an ID that is taken, QEMU can just say sorry = that ID is already >>>> taken. I could just increment the ID myself until I find one that = is unique. It is a >>>> simple algorithm. Maybe you are talking about some program that has = hard coded >>>> ID's it depends on. If that is the case, perhaps this management = program could be >>>> made to be a little flexible. Or use a 160-bit SHA-1 generated ID = that is virtually >>>> guaranteed to always be unique. >>>=20 >>> If breaking existing apps was OK, we would just mandate that users = always >>> provide an ID which trivially avoids the problem of not having an ID = to >>> use when deleting the object. We want to /avoid/ breaking existing = apps >>> though, so saying an app should change the way it works in order to = cope >>> with QEMU's ID generation is not appropriate. Hence any use of = auto-generated >>> IDs, must use a separate namespace to avoid such clashes. >>=20 >> This is making the assumption that an auto-generated ID system would = break any existing >> application. We don't know this. In fact, I predict a future patch = would allow existing >> applications to continue running without modification. The patch = would be a win-win >> for both users and any management application. >>=20 >=20 > Daniel's assumption is spot on. The idea of "QEMU can just say sorry > that ID is already taken" will break existing applications. >=20 > But we are all striving to make your prediction true, with this very > conversation. Ok, it sounds like some are concerned that Libvirt would not be able to = work with this feature. Let me ask you this: does Libvirt interact with QEMU before the = user has a chance to do so? If the answer is yes, then that means Libvirt will have = finished=20 creating all its devices with their ID's long before the user has a = chance to enter his own devices.=