>>> On 02.05.16 at 10:55, <roger....@citrix.com> 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?) Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
