From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH XEN v5 07/23] tools: Refactor /dev/xen/gnt{dev, shr} wrappers into libxengnttab. Date: Mon, 23 Nov 2015 17:05:39 +0000 Message-ID: <1448298339.4973.77.camel@citrix.com> References: <1447070397.27774.11.camel@citrix.com> <1447070458-31104-1-git-send-email-ian.campbell@citrix.com> <1447070458-31104-8-git-send-email-ian.campbell@citrix.com> <22083.22696.351853.213216@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <22083.22696.351853.213216@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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.