Re: [PATCH XEN v4 07/23] tools: Refactor /dev/xen/gnt{dev, shr} wrappers into libxengnttab.

[Ian Campbell <ian.campbell@citrix.com>]

On Thu, 2015-10-29 at 16:28 +0000, Wei Liu wrote:
> On Wed, Oct 21, 2015 at 04:23:14PM +0100, Ian Campbell wrote:
> > libxengnttab will provide a stable API and ABI for accessing the
> > grant table devices.
> > 
> > The functions are moved into the xengnt{tab,shr} namespace to make a
> > clean break from libxc and avoid ambiguity regarding which interfaces
> > are stable.
> > 
> > XXX consider combining into a single namespace (i.e. with
> > xengnttab_handle having two open fd's in it on Linux)
> > 
> 
> This?

Currently there are two separate interfaces (i.e. 2x_open, 2x handle types,
2x sets of functions for using the handle, 2x namespaces, etc) in this
library corresponding to two underlying devices in /dev/xen, one of which
is for utilising grant references which you have been given (gntdev), the
other of which is for allocating suitable memory for granting and creating
grants of it to give away to others (gntshr).

Only Linux and mini-os implement gntshr today, I think.

AFAIK most consumers (e.g. qemu's pv backends, or userspace pv backends
generally) are only using the first (consuming grants). The only user of
gntshr I know of is libvchan, but in general any userspace frontend would
likely need this functionality.

There are three possibilities here for the stable library interface:
 * Do nothing, keep it as two interfaces in one library.
 * Split into separate libgntdev and libgntshr libraries.
 * Unify the two APIs such that a single handle actually contains two fd's
   and functions are all in the same namespace etc and just the correct
   underlying fd associated with the op.

The comment is wondering if we should do the third, I hadn't thought of the
middle one at the time.

Right now my preference is towards the first, the implementation of which
is "delete the XXX comment".

The downside of not merging is that if some new OS port comes along which
has gntdev and gntshr in a single device that the applications then still
have to open and manage two handles and updating the ABI to unify them
later would be a pain.

I'm inclined towards lazily thinking that having two handles is not such a
big deal, even on an OS where the underlying implementation is such that
they contain "redundant" file handles.

Ian.