|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH 05/11] libxl: Provide libxl_domain_rename
Vincent Hanquez writes ("Re: [Xen-devel] [PATCH 05/11] libxl: Provide
libxl_domain_rename"):
> 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.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|