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

[Jeff Cody]

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