Re: [Qemu-devel] Should we auto-generate IDs?

[Programmingkid]

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