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

["Daniel P. Berrange" <berrange@redhat.com>]

On Thu, Aug 27, 2015 at 09:56:47AM -0400, Programmingkid wrote:
> 
> On Aug 27, 2015, at 9:49 AM, Daniel P. Berrange wrote:
> 
> > On Thu, Aug 27, 2015 at 09:33:42AM -0400, Programmingkid wrote:
> >> 
> >> On Aug 27, 2015, at 8:32 AM, Jeff Cody wrote:
> >> 
> >>> 
> >>> 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.
> > 
> > If we did have auto-generated names, we would need to come up with a
> > scheme that is not going to clash with any existing naming that users
> > of QEMU may already be doing, otherwise we risk causing a regression.
> > Something as simple as what you suggest has non-trivial chance of
> > clashing.
> 
> Actually there is a way to prevent clashing. When QEMU auto-generates a
> name, it could scan all the ID's to see if there is a clash. If the ID is already
> taken, just increment the ID until it is detected to be unique. The previous
> threads on this subject has patches that did just that. This means that a
> ID scheme that is just a single number would work without clashes.

Nope that is not sufficient. Consider an application was doing the
following

  $ qemu -device virtio-blk ....  -monitor stdio
  (qemu) device_add virtio-blk,id=ub1

Now if QEMU assigns the disk specified on the command line the
ID value 'ub1', the user later attempts to hotplug a disk
with that same ID will fail. So it will cause a regression
where something an app was doing with old QEMU will now
result in an error.

We don't know what possible naming schemes an app may already
be using with QEMU, so the only safe thing is to invent an
ID format which is currently illegal to specify manually, so
we have a completely separate namespace for auto-generated
IDs from user generated IDs.

> > We should look at what characters QEMU currently forbids users
> > from using in an explicitly passed ID, and include one or more
> > of them in the name.  eg IIUC, QEMU forbids use of a leading
> > underscore in ID names, so auto-generated names could use an
> > leading _ to avoid clashing.
> 
> I'm thinking that it might be unnecessary to do all that. ID clash
> detection is pretty easy to do. 

We really do need todo this.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|