Re: [PATCH XEN v5 09/23] tools: Refactor hypercall calling wrappers into libxencall.

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

On Fri, 2015-11-13 at 15:16 +0000, Ian Campbell wrote:
> 
> If we are going to standardise on one of those then given we've gone for
> -1/errno in most other places and it's the "normal" way to do things I
> think we should do the same here and the freebsd driver in libxencall
> should set errno.
> 
> There are other alternatives, such as having this library return the
> "privcmd ioctl" result in its return value + errno and the "hypercall
> result" in a separate output pointer argument. This would require, possibly
> substantial, changes in the callers, but right now they are all in libxc,
> which could munge that back into the current somewhat braindead scheme
> allowing us to update those call paths piecemeal and allowing new users to
> use the sane interface.
> 
> Thoughts?

Ian and I discusses this IRL. We decided that an interface that required
the caller to check two error returns (the "privcmd ioctl result" and the
"hypercall result" was unwieldy).

As a result we've decided that -1/errno=EFOO is the best approach, but that
we should try and partition the errno space (so far as possible given the
existing hypercall interfaces) into "From hypercall" and "From OS machinery
for making hypercalls" where it matters.

For some cases the distinction may not be so important (e.g. EFAULT from
either the kernel reading the ioctl arg or the hypervisor reading the
hypercall arg). But in other cases it might be relevant (e.g. EPERM from
the hypervisor vs a permissions error relating to the privcmd fd having
been locked to a particular domain at the kernel/process level).

Ian.

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