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 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

I think this adds more complexity, when we could solve it by only using 
error codes that are part of the POSIX standard, and that are present on all 
UNIX systems.

> > --- a/xen/include/public/errno.h
> > +++ b/xen/include/public/errno.h
> > @@ -93,7 +93,6 @@ XEN_ERRNO(ENAMETOOLONG,   36)     /* File name too long */
> >  XEN_ERRNO(ENOLCK,  37)     /* No record locks available */
> >  XEN_ERRNO(ENOTEMPTY,       39)     /* Directory not empty */
> >  XEN_ERRNO(ENOSYS,  38)     /* Function not implemented */
> > -XEN_ERRNO(ENODATA, 61)     /* No data available */
> >  XEN_ERRNO(ETIME,   62)     /* Timer expired */
> >  XEN_ERRNO(EBADMSG, 74)     /* Not a data message */
> >  XEN_ERRNO(EOVERFLOW,       75)     /* Value too large for defined data 
> > type */
> 
> And in absolutely no case can you unconditionally remove _anything_
> from other than the tools-only parts of the public interface.

Right, the problem with leaving it there is that I'm quite certain it's 
going to be used again as a return value from a hypercall.

Roger.

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