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