qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Programmingkid
Subject: Re: [Qemu-devel] Should we auto-generate IDs?
Date: Thu, 27 Aug 2015 10:54:07 -0400

On Aug 27, 2015, at 10:06 AM, Daniel P. Berrange wrote:

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

Yes adding a device with an ID that is taken would not work. Maybe
QEMU could help you in this situation. If in the above scenario, the user
were to issue a device_add using a already used ID, QEMU could tell
the user that that ID is taken, but it can have this auto-generated ID. 
Instead of being able to use ub1, QEMU could say:

Note: ID ub1 taken, use ub2 instead? [y] [n]

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

Numbers go on forever. No matter what naming scheme an application
might be using, QEMU could just add one to the highest taken number
and solve the problem.

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

I think most people will be ok with using an underscore in an auto-generated
ID system. The underscore rule sounds good. It would have the look of
a machine generated ID. 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]