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

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

On Mon, 2015-11-23 at 17:05 +0000, Ian Campbell wrote:

Adding Daniel who I should have included the first time, plus a few
more thoughts from me at the end.

> On Wed, 2015-11-11 at 15:03 +0000, Ian Jackson wrote:
> > > XXX consider combining into a single namespace (i.e. with
> > > xengnttab_handle having two open fd's in it on Linux)
> > 
> [...]
> > I conclude it would be better to unify them.
> 
> Starting to look into this I have some queries on the direction I ought to
> take.
> 
> Currently the real world implementations are such that a given installation
> either provides:
>  * Neither gnttab nor gntshr (*BSD)
>  * Only gnttab, not gntshr (mini-os, older Linux versions)
>  * Both gnttab and ghtshr (newer Linux versions)
> 
> In particular gntshr but not gnttab is not found in any real world system.
> Should I plan for such systems existing in the API? I think I probably
> should.
> 
> A second question is then what functionality should be provided for callers
> who only want either gnttab or gntshr, but not both. (The canonical example
> would be the xc_gntshr_* compat layer in libxenctrl, there may be others).
> 
> Previously code could rely on either xc_gnt{tab,shr}_open failing if the
> underlying interface was not present, and react accordingly, which might
> involve disabling functionality entirely (in such a way as the other calls
> to xc_gnt{tab,shr}_* do not need to handle ENOSYS, including by calling
> exit(1)).
> 
> Now xengnttab_open could succeed because the other interface is available,
> which may cause these applications to think they have an interface which
> they in reality do not => confusion.
> 
> Options I can think of:
> 
>  * A set of open flags, either FOO_MANDATORY or FOO_ONLY (the latter
>    allowing us to skip opening the relevant interface).
>  * Provide an interface to query the actual functionality which a given
>    handle supports, so apps can react accordingly (e.g. by closing it again
>    and erroring)
>  * Force all callers to adjust to handling ENOSYS as part of this
>    transition
> 
> Opinions?

Thinking about this some more overnight, it occurred to me that the
real issue is that gnttab and gntshr are actually two quite difference
APIs. gnttab is all about consuming grant references which are given to
you from elsewhere while gntshr is all about creating grant references
to give to others. They have relatively little in common wrt the
underlying infrastructure, e.g. gnttab is mostly about making GNTTABOP
hypercalls while gntshr mostly interacts with the kernel's grant ref
allocator with no interaction with the hypervisor.

Maybe that and the API issues above constitute an argument for not
combining, I'm really not sure.

Ian.