From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUxfj-0005CO-8h for qemu-devel@nongnu.org; Thu, 27 Aug 2015 09:56:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUxff-0003jN-55 for qemu-devel@nongnu.org; Thu, 27 Aug 2015 09:56:55 -0400 Received: from mail-qg0-x234.google.com ([2607:f8b0:400d:c04::234]:36287) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUxfe-0003jI-Vi for qemu-devel@nongnu.org; Thu, 27 Aug 2015 09:56:51 -0400 Received: by qgeb6 with SMTP id b6so11057485qge.3 for ; Thu, 27 Aug 2015 06:56:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Programmingkid In-Reply-To: <20150827134943.GS24486@redhat.com> Date: Thu, 27 Aug 2015 09:56:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <37557843-A1BA-4822-9933-B0B8AD588C90@gmail.com> References: <441C227A-2CF0-43AE-AC7F-B066708CEABD@gmail.com> <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> <56530C98-D6B3-417E-BB58-E29412283BF1@gmail.com> <20150827134943.GS24486@redhat.com> Subject: Re: [Qemu-devel] Should we auto-generate IDs? 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 , jsnow@redhat.com, =?iso-8859-1?Q?Andreas_F=E4rber?= On Aug 27, 2015, at 9:49 AM, Daniel P. Berrange wrote: > On Thu, Aug 27, 2015 at 09:33:42AM -0400, Programmingkid wrote: >>=20 >> On Aug 27, 2015, at 8:32 AM, Jeff Cody wrote: >>=20 >>>=20 >>> On the generation scheme proposed above: >>>=20 >>> I understand that something you desire is an ID that is easier to >>> type. >>>=20 >>> If we wanted to make it shorter, perhaps we could have the number >>> counter be variable length: >>>=20 >>> qemu#ss#D#XY >>> | | | | >>> qemu reserved - | | | >>> | | | >>> subsystem name ---| | | >>> | | >>> counter --------| | >>> | >>> 2-digit random ---| >>>=20 >>>=20 >>> The counter would just grow to however many digits are needed. = There >>> is another benefit to growing that number as well - we can use >>> whatever integer size we think is adequate in the code, without >>> affecting the generation scheme. >>>=20 >>> -Jeff >>=20 >> This system does seem easy to type. Do we need the "qemu" part? >> It seems unnecessary. Maybe we could do this: >>=20 >> >>=20 >> Examples: >> For the third block device it would look like this: bl3 >> For the seventh USB device it would look like this: ub7 >>=20 >> Each subsystem would receive a two character code. >=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. 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 > We should look at what characters QEMU currently forbids users > from using in an explicitly passed ID, and include one or more > of them in the name. eg IIUC, QEMU forbids use of a leading > underscore in ID names, so auto-generated names could use an > leading _ to avoid clashing. I'm thinking that it might be unnecessary to do all that. ID clash detection is pretty easy to do.=20=