Re: [Xen-devel] [PATCH 6/8] libxl: allow a generation ID to be specified at domain creation

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 18/06/14 13:25, Ian Campbell wrote:
> On Wed, 2014-06-18 at 13:09 +0100, David Vrabel wrote:
>> On 18/06/14 12:33, Ian Campbell wrote:
>>> On Thu, 2014-06-12 at 16:04 +0100, David Vrabel wrote:
>>>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>>>> index f0f6e34..1c5e687 100644
>>>> --- a/tools/libxl/libxl_types.idl
>>>> +++ b/tools/libxl/libxl_types.idl
>>>> @@ -371,6 +371,8 @@ libxl_domain_build_info = Struct("domain_build_info",[
>>>>                                         ("xen_platform_pci", 
>>>> libxl_defbool),
>>>>                                         ("usbdevice_list",   
>>>> libxl_string_list),
>>>>                                         ("vendor_device",    
>>>> libxl_vendor_device),
>>>> +                                       # See libxl_ms_vm_genid_generate()
>>>> +                                       ("ms_vm_genid",      libxl_uuid),
>>>
>>> When we discussed this IRL I thought we had decided that this should be
>>> a new libxl_ms_vm_genid type, effectively a typedef of uint8_t[16],
>>> similar to libxl_mac and libxl_hwcap[[0]]. This would avoid any
>>> suggestion that one of the more structured forms of UUID would be
>>> appropriate here.
>>
>> I kept the libxl_uuid type in the end because it allowed me to use
>> libxl_uuid_is_nil() without having to re-implement an equivalent.
> 
> Doesn't sound too tricky though.
> 
>>> I appreciate that you tried to address that with the comment, but I fear
>>> it might not be terribly effective in practice...
>>
>> A toolstack author cannot use the ms_vm_genid field correctly without
>> reading the Microsoft document and that's clear on the requirements.
> 
> What's not clear is that libxl_uuid_generate() doesn't (necessarily)
> meet the spec. Using a different type would stop people from using that.
> 
>> Do you still want a new typedef?
> 
> I think it would be best.

I started doing this and I now disagree (even more).

Using a new types requires duplicating the uuid json pack/unpack code
and prevents toolstacks from using standard uuid library functions for
dealing with the generation ID (e.g., if they need to (un)serailize the
ID or store it in a database etc.).

The benefits of using libxl_uuid out weight your concern that some one
might not use the documented function for generating a valid ID, IMO.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel