From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39622) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUyON-0000cF-F0 for qemu-devel@nongnu.org; Thu, 27 Aug 2015 10:43:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUyOK-0005V4-0I for qemu-devel@nongnu.org; Thu, 27 Aug 2015 10:43:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33713) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUyOJ-0005V0-Pp for qemu-devel@nongnu.org; Thu, 27 Aug 2015 10:42:59 -0400 Date: Thu, 27 Aug 2015 15:42:53 +0100 From: "Daniel P. Berrange" Message-ID: <20150827144253.GX24486@redhat.com> References: <20150826180815.GK11016@localhost.localdomain> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] Should we auto-generate IDs? Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Programmingkid Cc: Kevin Wolf , jsnow@redhat.com, Jeff Cody , Markus Armbruster , qemu-devel qemu-devel , Paolo Bonzini , Andreas =?utf-8?Q?F=C3=A4rber?= On Thu, Aug 27, 2015 at 10:34:05AM -0400, Programmingkid wrote: > > On Aug 27, 2015, at 10:02 AM, Eric Blake wrote: > > > On 08/27/2015 07:56 AM, Programmingkid wrote: > > > >>> 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. > >> > >> 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. > > > > 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. > > 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. 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. > > What about this scenario. There are 1 million devices added to QEMU, and I need to > add a device with an ID. Each of the 1 million devices already have an ID. If I don't want > to try to find a unique ID myself, having QEMU do it for me would make things much easier. > How would I find this device's ID? I could issue some kind of monitor command that gives me > the ID. This feature doesn't appear to be implemented yet. This will change. A future > ' info all-devices ' command would probably do it. If you're working at that kind of scale, then honestly apps are already just going to be specifying an ID explicitly so we have no problem. It is orders of magnitude simpler todo that than to try to parse any 'info all-devices' output in order to determine QEMU's auto-generated ID value. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|