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: >> >> <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. >>
