This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH 05/11] libxl: Provide libxl_domain_rename

Vincent Hanquez writes ("Re: [Xen-devel] [PATCH 05/11] libxl: Provide 
> On 25/03/10 19:04, Ian Jackson wrote:
> > Provide a new function libxl_domain_rename.  It can check that the
> > domain being renamed has the expected name, to avoid races.
> >
> > Use the new function to set the name during domain creation.
> this looks really ugly (transaction in transaction in domain make), and 
> has a really complicated code path (which doesn't look right either on 
> the first read), but

There is no transaction in transaction.  This arrangement is necessary
because the (re)name action which is part of domain creation is
already part of a transaction.  I didn't much like the "goto"-based
retry loop but that's the way it's done in the domain creation too.

> my main objection is that libxl has no business handling the uniqueness 
> of names or whatever you want to do here. libxl get a name string from 
> whoever is using it (xl in your case), so if you want somehow to have a 
> special feature make it so in xl. in other words, no policies in libxl.

You are confused.  The purpose of this check is to check that the
existing name is as expected, not that the name is not unique
(although the lack of checking that the name is unique is also a bug).

The reason we need to check that the existing name is as expected is
to ensure that we effectively "lock" the domain against multiple
simultaneous migration attempts.

> also NULL is for pointer, 0 for integer values.

0 is a perfectly acceptable null pointer constant.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>