Re: [Xen-devel] Xen 4.2 Release Plan / TODO

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-04-12 at 08:35 +0100, Ian Campbell wrote:
> 
> > ]   char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int
> use_long);
> > ]   int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid);
> > ]   int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid);
> > ]   int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid);
> > ]   int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name,
> > ]                      uint32_t set);
> > ]   int libxl_tmem_shared_auth(libxl_ctx *ctx, uint32_t domid, char*
> uuid,
> > ]                              int auth);
> > ]   int libxl_tmem_freeable(libxl_ctx *ctx);
> > 
> > Not sure about the tmem calls.
> 
> Me neither. 

Dan,

We want to declare the libxl 4.2 API as "stable" so we are trying to
determine whether any of these functions need to be made potentially
asynchronous or not, i.e. if they may be "slow" per the definition under
the comment "Machinery for asynchronous operations ("ao")" in
tools/libxl/libxl_internal.h, effectively if they may block for extended
periods.

If they were then we would possibly want to change the API to take an
"ao_how" as described under "Some libxl operations can take a long time"
in tools/libxl/libxl.h

If they are "fast" today but could potentially be slow in the future
then we may be able to make the trivial API change but keep the
synchronous implementation (depending on the specifics). It's quite late
in the day so if the functions are "slow" then this would be the
preferred option at this stage.

Otherwise the alternative is that we have to maintain these interfaces
going forward (for compat) and perhaps be forced introduce a new
parallel async interface in the future. Annoying but not the end of the
world.

Ian.


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