[Xen-devel] [PATCH 00 of 27 v3] libxl: rationalise libxl_device_* APIs

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

The following series overhauls the libxl_device_* APIs in an attempt
to make them more consistent across the types of devices and move
towards something we can support as a stable API longterm.

This is broadly speaking the changes I discussed in [0]

One of the early patches adds a big comment describing the API. It
would be useful if this got a particularly close eye with a view to
supporting it long term -- especially from actual and potential
consumers of the API (of who I've CC a few who sprang to mind).

Along the way I filed some rough edges of the internal implementation
of this stuff but my primary concern is to make the public facing API
one that we can commit to keeping stable.

One aspect which is missing is the ability to do asynchronous
add/remove etc. This requires the overhaul of the libxl event system
which Ian Jackson described at [1]. I did bear this in mind so
hopefully I have provided the majority of the necessary moving parts
internally.

Changes since last time:
  - Correct handling of result of libxl__device_remove wait
    vs. not-wait. We need to indicate to the caller if they need to
    wait or not.
  - Decide it's definitely correct to not trust the frontend dir.

Changes since the time before that:
  - Rename type "destructor" functions to "dispose" freeing up the
    verb "destroy" to mean, uh, destroying things, such as a forcible
    remove of a device or destroying a domain.
  - Use this new found freedom to s/force_remove/destroy/.
  - Added a flags parameter to libxl_ctx_alloc. Might as well have one
    for future flexibility
  - Updated language bindings to use new scheme.

[0] http://www.gossamer-threads.com/lists/xen/devel/204668
[1] http://www.gossamer-threads.com/lists/xen/devel/212580
 &  http://www.gossamer-threads.com/lists/xen/devel/212578
 &  http://www.gossamer-threads.com/lists/xen/devel/212579
 &  http://www.gossamer-threads.com/lists/xen/devel/212581

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel