Re: [Xen-devel] [PATCH v1 07/12] libxl: add prepare/unprepare operations to the libxl public interface

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On 15/03/13 13:20, Ian Jackson wrote:
> Roger Pau Monne writes ("Re: [Xen-devel] [PATCH v1 07/12] libxl: add 
> prepare/unprepare operations to the libxl public interface"):
>> On 13/03/13 17:19, Ian Jackson wrote:
>>> I'm not sure I understand how the caller is supposed to use this.
>>
>> The caller should execute prepare before adding the disk (hopefully in a
>> not performance sensitive path).
> 
> That's a non-backward-compatible API change, then ?  We're trying to
> avoid those.

It is backward compatible if the caller only uses v1 hotplug scripts. If
the caller wishes to use v2, then it has to call prepare.

> 
>>> How does the eventual script manage to correlate the preparation with
>>> the unpreparation ?
>>
>> You call the script with the prepare or unprepare parameters, so the
>> script knows which action it has to execute.
> 
> No, I mean, is it just the target string that is relevant for
> identifying the preparation ?  Can the same disk be prepared multiple
> times (eg for multiple guests) ?  How is this synchronised ?

Yes, since everything is stored in terms of <domid>/<devid>, the same
"params" line can be used in multiple guests.

> 
>> The only downfall of not calling prepare before add is that libxl will
>> thread this device as using the v1 hotplug interface, so old users of
>> libxl will still have the same functionality, but they will not be able
>> to use new hotplug scripts using the v2 interface.
> 
> Perhaps it would be better to hide this from the caller and implement
> the old API in terms of the new one ?

The advantage of this new hotplug calling convention is that you are
allowed to call prepare and add at different points, so you can offload
work done in the add phase to the prepare call.

That being said, this public prepare function is only used for
block-attach, so I'm not sure if we are interested in doing any kind of
offloading there (since it's not a critical path), so I might as well
remove the public prepare/unprepare functions and do it all inside add.


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