From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48169) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUyrt-0006lR-NL for qemu-devel@nongnu.org; Thu, 27 Aug 2015 11:13:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUyro-0006D3-MH for qemu-devel@nongnu.org; Thu, 27 Aug 2015 11:13:33 -0400 Received: from mail-qk0-x229.google.com ([2607:f8b0:400d:c09::229]:36554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUyro-0006Cx-Cc for qemu-devel@nongnu.org; Thu, 27 Aug 2015 11:13:28 -0400 Received: by qkda128 with SMTP id a128so11938933qkd.3 for ; Thu, 27 Aug 2015 08:13:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Programmingkid In-Reply-To: <20150827140707.GD2669@localhost.localdomain> Date: Thu, 27 Aug 2015 11:13:25 -0400 Content-Transfer-Encoding: 7bit Message-Id: <4E7FD2A3-C967-4D30-A657-548D27BCC84B@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> <20150827140707.GD2669@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 , Markus Armbruster , qemu-devel qemu-devel , Paolo Bonzini , jsnow@redhat.com, =?iso-8859-1?Q?Andreas_F=E4rber?= On Aug 27, 2015, at 10:07 AM, Jeff Cody wrote: > On Thu, Aug 27, 2015 at 09:33:42AM -0400, Programmingkid wrote: >> >> On Aug 27, 2015, at 8:32 AM, Jeff Cody wrote: >> > > [snip] > >>> >>> I'm not married to the ID generation scheme I proposed. >>> >>> What I am trying to do, however, is have a technical discussion on >>> generating an ID in a well-formed manner. And hopefully, in a way >>> that is useful to all interested subsystems, if possible. >>> >>> Do you disagree with the requirements I listed above? If so, it would >>> be useful to begin the discussion around that. For ease of >>> discussion, I'll list them again: >>> >>> * Reserved namespaces >>> * Uniqueness >>> * Non-predictable (to avoid inadvertently creating a de facto ABI) >> >> Uniqueness is a must. > > Agree > >> Reserve namespaces? Why do we need to do this? > > We need to prevent the user from selecting, inadvertently, the same ID > as a generated one. This may also be harder to have consistent across > all subsystems. If preventing the user from entering the same ID as a generated one is that important, enforcing rules on ID's could work. This is what might work: QEMU's auto-generated ID's much begin with an underscore. Example: _34. User ID's cannot start with an underscore. Example: 34. * No auto-generated/User ID clashes * Easy to type * Management application probably don't use underscores at the beginning of an ID making it safe for them. > >> What is wrong with having a predictable ID? >> > > As Daniel and Eric have noted, it could be nice to have a predictable > ID. My concern with a predictable ID is that it creates, across > multiple sub-systems, an ABI that we will then need to make sure > always works. > > For instance, I don't want management software or a user to rely on us > parsing devices, or image filenames / block driver states in a certain > order, and then anticipate the ID name. I am concerned about creating > an interface that may inadvertently "break" later on, and imposing a > burden on QEMU that isn't reasonable. Perhaps it is enough to just > rely on documentation for this, without enforcing it in the scheme. If we do nothing, QEMU stays broken. The monitor command device_del and others that need an ID will not work still. Hopefully any changes we make to QEMU will be robust enough stand the test of time. > >> Maybe we need to discuss where this ID is going to be used. I know I >> need it for the device_del monitor command. Any other places you or >> anyone else knows it is used? >> > > In the block layer, we have BlockDriverStates, that represent image > nodes and backing files. If we have a chain such as this: > > > Virtio0: > > [base] <--- [filenameA] <--- [filenameB] > > We used to reference an individual node by the device string (e.g. > "virtio0"), in conjunction with the filename. The problem was, that > this was prone to error. A node-name was added, which is essentially > a unique identifier for each device. So then block commands (such as > block jobs) could reference a node in an unambiguous manner. > > This is the area for an auto-generated ID that I was focused on. I'm not very familiar with this system. If auto-generated ID's could harm this system, then maybe this system should be left alone by the auto-generation feature. > >>> . . >>> >>> On the generation scheme proposed above: >>> >>> I understand that something you desire is an ID that is easier to >>> type. >>> >>> If we wanted to make it shorter, perhaps we could have the number >>> counter be variable length: >>> >>> qemu#ss#D#XY >>> | | | | >>> qemu reserved - | | | >>> | | | >>> subsystem name ---| | | >>> | | >>> counter --------| | >>> | >>> 2-digit random ---| >>> >>> >>> 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. >>> >>> -Jeff >> >> This system does seem easy to type. Do we need the "qemu" part? >> It seems unnecessary. Maybe we could do this: >> >> >> >> Examples: >> For the third block device it would look like this: bl3 >> For the seventh USB device it would look like this: ub7 >> >> Each subsystem would receive a two character code. >>