From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55511) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUxpk-0006pI-4m for qemu-devel@nongnu.org; Thu, 27 Aug 2015 10:07:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUxpf-0001ZQ-EW for qemu-devel@nongnu.org; Thu, 27 Aug 2015 10:07:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34316) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUxpf-0001Yz-87 for qemu-devel@nongnu.org; Thu, 27 Aug 2015 10:07:11 -0400 Date: Thu, 27 Aug 2015 10:07:07 -0400 From: Jeff Cody Message-ID: <20150827140707.GD2669@localhost.localdomain> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56530C98-D6B3-417E-BB58-E29412283BF1@gmail.com> Subject: Re: [Qemu-devel] Should we auto-generate IDs? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Programmingkid Cc: Kevin Wolf , Markus Armbruster , qemu-devel qemu-devel , Paolo Bonzini , jsnow@redhat.com, Andreas =?iso-8859-1?Q?F=E4rber?= 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. > 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. > 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. > > . . > > > > 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. >