On Thu, 2015-12-17 at 17:06 +0000, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jack...@eu.citrix.com>
> ---
>  mg-schema-test-database |   14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/mg-schema-test-database b/mg-schema-test-database
> index a4cb732..4e0ee68 100755
> --- a/mg-schema-test-database
> +++ b/mg-schema-test-database
> @@ -448,12 +448,22 @@ END
>       done
>  
>       # As we copy, we note everything we're not borrowing as
> -     # belonging to the parent db.
> +     # belonging to the parent db.  We borrow shares of a shared
> +     # resource.  If we borrow only some rather than all of the
> +     # shares, neither DB will be able to unshare it.

This is what actually happens, rather than this comment explaining a thing
we are avoiding, right?

I ask because although the text (and the use of "properly" in the subject)
seems pretty clear it's the former I was surprised to find this code was
borrowing partial shares and therefore setting up such a situation. Given
the caveat below would it not be better to just never allow this? I suppose
that given the list of tasks to borrow came from the user this might be
considered a "keep both pieces" situation.

> +
> +     # In principle it might be possible to actually use different
> +     # shares of the same resource with different dbs.  However the
> +     # `sharetype' contains the osstest revision, which prevents
> +     # sharing between test and real versions of osstest code.
> +
>       cat >>$t.import <<END
>               $(make_xdbref_task $maindbname 'not borrowed' '' PARENT)
>               UPDATE resources
>                       SET owntaskid = $(taskid xdbref $maindbname)
> -                     WHERE owntaskid != $(borrowtaskid $task);
> +                     WHERE owntaskid != $(borrowtaskid $task)
> +                       AND owntaskid != $(taskid magic shared)
> +                       AND owntaskid != $(taskid magic preparing);
>               COMMIT;
>  END
>  

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

Reply via email to