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: > > <subsystem name><counter> > > 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. >
