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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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?

Ian.

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