All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: xen-devel@lists.xenproject.org,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [PATCH 6/8] libxl: allow a generation ID to be specified at domain creation
Date: Wed, 18 Jun 2014 13:25:49 +0100	[thread overview]
Message-ID: <1403094349.25575.22.camel@kazak.uk.xensource.com> (raw)
In-Reply-To: <53A1817A.5090102@citrix.com>

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.

  reply	other threads:[~2014-06-18 12:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-12 15:04 [PATCHv5 0/8] tools: rework VM Generation ID David Vrabel
2014-06-12 15:04 ` [PATCH 1/8] libxc: allow xc_get/set_hvm_param() to get/set 64-bit values David Vrabel
2014-06-18 11:26   ` Ian Campbell
2014-06-18 13:05   ` Ian Campbell
2014-06-12 15:04 ` [PATCH 2/8] libxl: add libxl__random_bytes() which fills a buffer with random bytes David Vrabel
2014-06-18 11:28   ` Ian Campbell
2014-06-18 11:43     ` Roger Pau Monné
2014-06-18 13:10       ` Ian Campbell
2014-06-12 15:04 ` [PATCH 3/8] hvmloader: add helper functions to get/set HVM params David Vrabel
2014-06-12 15:04 ` [PATCH 4/8] hvm: add HVM_PARAM_VM_GENERATION_ID_ADDR David Vrabel
2014-06-12 15:04 ` [PATCH 5/8] libxc, libxl, hvmloader: strip out outdated VM generation ID implementation David Vrabel
2014-06-12 15:04 ` [PATCH 6/8] libxl: allow a generation ID to be specified at domain creation David Vrabel
2014-06-18  5:18   ` Hongyang Yang
2014-06-18  9:38     ` David Vrabel
2014-06-18  9:39       ` Ian Campbell
2014-06-18 11:33   ` Ian Campbell
2014-06-18 12:09     ` David Vrabel
2014-06-18 12:25       ` Ian Campbell [this message]
2014-06-18 13:22         ` David Vrabel
2014-06-12 15:04 ` [PATCH 7/8] xl: generate a new random VM generation ID if requested David Vrabel
2014-06-18 11:37   ` Ian Campbell
2014-06-12 15:04 ` [PATCH 8/8] docs: update docs for the ~/platform/generation-id key David Vrabel
2014-06-18 16:12 [PATCHv6 0/8] tools: rework VM Generation ID David Vrabel
2014-06-18 16:12 ` [PATCH 6/8] libxl: allow a generation ID to be specified at domain creation David Vrabel
2014-06-27 11:16   ` Ian Campbell
2014-06-27 11:35     ` David Vrabel
2014-06-27 12:23       ` Ian Campbell
2014-06-27 12:51   ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1403094349.25575.22.camel@kazak.uk.xensource.com \
    --to=ian.campbell@citrix.com \
    --cc=david.vrabel@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.