Re: [Xen-devel] [PATCH XEN v2 05/15] tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn.

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-07-15 at 16:46 +0100, Ian Campbell wrote:
> diff --git a/tools/libxenevtchn/include/xenevtchn.h
> [...]

> +/* A port identifier is guaranteed to fit in 31 bits. */
> +typedef int evtchn_port_or_error_t;
> 
[...]
> +/*
> + * Returns a new event port awaiting interdomain connection from the given
> + * domain ID, or -1 on failure, in which case errno will be set 
> appropriately.
> + */
> +evtchn_port_or_error_t
> +xenevtchn_bind_unbound_port(xenevtchn_handle *xce, int domid);
> +
> +/*
> + * Returns a new event port bound to the remote port for the given domain ID,
> + * or -1 on failure, in which case errno will be set appropriately.
> + */
> +evtchn_port_or_error_t
> +xenevtchn_bind_interdomain(xenevtchn_handle *xce, int domid,
> +                           evtchn_port_t remote_port);

ISTR that this evtchn_port_or_error_t construct was introduce in order to
correct an incorrect type used here without changing the API in annoying
ways.

Given that this series is already changing the API anyway do we want to
take the opportunity prior to declaring this new library ABI/API stable to
rework these functions such that they return 0 or -1 and take a
evtchn_port_t * output variable which they update on success?

And then abolish evtchn_port_or_error_t except for the
 XC_WANT_COMPAT_EVTCHN_API case.

Ian.

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