[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH XEN v5 09/23] tools: Refactor hypercall calling wrappers into libxencall.
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@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |