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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

Ian.


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