Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote:
> >>> On 29.04.16 at 17:06, <roger.pau@xxxxxxxxxx> wrote:
> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
> >> >>> On 29.04.16 at 16:21, <roger.pau@xxxxxxxxxx> wrote:
> >> > According to the POSIX standard for error codes [0], ENODATA is both
> >> > obsolescent (so it may be removed in the future) and optional.
> >> 
> >> It being optional still doesn't preclude us using it.
> >> 
> >> > Replace it's
> >> > usage with ENOENT, which seems like the closest match. Both FreeBSD and
> >> > OpenBSD don't have this error code in the native errno.h headers.
> >> 
> >> There's no rule saying that Xen's errno set must match any other OS'es.
> >> That's one of the reasons why we (finally) separated ours.
> > 
> > I understand that, but doing this means that then on the toolstack side we 
> > need to start doing ifdefery in order to match values that are not present 
> > in the native OS. For example a check was added to libxl against 
> > XENVER_build_id returning ENODATA, this means that then on libxl I would 
> > have to add a:
> > 
> > #ifdef __FreeBSD__
> > #define ENODATA ENOENT
> > #endif
> 
> You ought to be using XEN_NODATA there anyway.

No, the privcmd driver is the one that performs the translation from Xen 
error codes into the OS error code space, so the tools just see error codes 
in the OS space. No tools at all use XEN_* error codes directly.

This is because privcmd does the translation, and because it would be 
impossible to differentiate if the errno returned by the ioctl belongs to 
Xen space or to the OS space.

Roger.

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