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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-06-11 at 12:47 +0100, David Vrabel wrote:
> On 11/06/14 12:01, Ian Campbell wrote:
> > On Wed, 2014-06-11 at 11:53 +0100, David Vrabel wrote:
> >> On 11/06/14 09:22, Ian Campbell wrote:
> >>> On Tue, 2014-06-10 at 18:59 +0100, David Vrabel wrote:
> >>>> On 10/06/14 12:01, Ian Campbell wrote:
> >>>>> On Tue, 2014-06-03 at 14:15 +0100, David Vrabel wrote:
> >>>>> Should we consider calling the API field name something more specific,
> >>>>> like "ms_vgid"? I'm thinking of the case where some other OS vendor
> >>>>> reinvents the wheel. (I don't care about the internals, just the API).
> >>>>
> >>>> generation_id matches the platform/generation-id xenstore key so I would
> >>>> keep the libxl field name as-is.
> >>>
> >>> One is an internal implementation detail (we can update libx? and
> >>> hvmloader in parallel if we have to) while the other is a stable API.
> >>
> >> The specification is for a generic, non-Microsoft specific ACPI device
> >> so I don't see the need to include ms_ in the field name.

BTW, the fact is that microsoft are defining the spec, regardless of
whether it is generic in nature, so I'm not really sure I buy this
argument.

e.g. if the Linux guys decided they wanted something similar but
incompatible with this spec and therefore a different ACPI device how
would we name that field to avoid confusion?

> > The name should reflect the spec then. acpi_vm_gen_counter perhaps
> > (matching the ACPI _CID)
> 
> It does match the spec;  "Generation ID" is the name of the feature.
> Using acpi_vm_gen_counter would just be confusing because the device
> does not provide a counter.

That's the name it has in the spec.

> >>>>> Do you not need to worry about endianess when memcpy'ing out of a uuid?
> >>>>
> >>>> No. The conversion of uuid to the two 64-bit integers is arbitrary, it
> >>>> need only be consistent.  The integers in guest memory are in native
> >>>> endianness.
> >>>
> >>> OK. I was wondering if we might want to preserve the byte order so as
> >>> not to trample any UUID format which is used.
> >>
> >> The specification doesn't require that the ID is a UUID.
> > 
> > True. It does say "cryptographically random integer value". Are you sure
> > that the result of libxl_uuid_generate meets that standard (rather than
> > say one of the non-crypto schemes for generating uniqueness)?
> 
> Yes (although it does only provide 122 bits of randomness but I think
> the trade-off of a convenient, UUID-base interface is worth it).

Even on BSD?

Ian.


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