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

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

On Mon, May 02, 2016 at 03:06:21AM -0600, Jan Beulich wrote:
> >>> On 02.05.16 at 10:55, <roger.pau@xxxxxxxxxx> wrote:
> > On Mon, May 02, 2016 at 12:22:35AM -0600, Jan Beulich wrote:
> >> But how would that help you? Would you mean to monitor future
> >> patches for not again introducing some use of ENODATA that the
> >> tool stack wants to explicitly check for? That would be quite tedious
> >> a task...
> > 
> > Yes it is, but TBH I cannot find any other solution. Adding ENODATA to the 
> > FreeBSD list of error codes seems quite pointless when there's no in-tree 
> > user of it.
> 
> That's a slightly strange way of looking at it: Shouldn't a component
> sitting on top of another component be capable of dealing with all
> output of that lower component, i.e. also any of the error codes that
> one may produce? In which case "no in-tree user" simply becomes a
> non-argument imo... (For comparison, consider a user mode library
> not itself using EINVAL: Would you say it's okay for the library to not
> care about EINVAL coming back from system calls?)

If it wasn't marked as optional and obsolescent I would have added it to 
FreeBSD without questioning, but the fact that the POSIX standard says that 
strictly conforming POSIX applications should not use it makes me wonder 
whether that is the right to do. ENODATA is the only error code that Xen 
uses that's not part of the core POSIX error codes.

IMHO Xen should be a strictly conforming POSIX application, it being a 
kernel that shares a common interface between a wide variety of different 
OSes.

I don't really want to make this any longer than necessary, so I think I'm 
going to try to get ENODATA added to the FreeBSD errno.h header, but I 
wouldn't be surprised if I found some resistance there, and TBH, I don't 
think I will be able to make a good point.

Roger.

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