Mising ENODATA

Tue Nov 22 22:46:16 UTC 2016

Op 22 nov. 2016 om 18:32 heeft Alan Somers <asomers at freebsd.org> het volgende geschreven:

> On Tue, Nov 22, 2016 at 4:44 AM, Willem Jan Withagen <wjw at digiware.nl> wrote:
>> On 23-5-2016 22:47, John Baldwin wrote:
>>> On Monday, March 14, 2016 03:08:42 PM Willem Jan Withagen wrote:
>>>> Hi,
>>>> 
>>>> According the standard is ENODATA an extention of errno.h defines...
>>>> 
>>>> http://pubs.opengroup.org/onlinepubs/9699919799/
>>>> 
>>>> The Open Group Base Specifications Issue 7
>>>> IEEE Std 1003.1, 2013 Edition
>>>> 
>>>> [ENODATA]
>>>>     [OB XSR] [Option Start]
>>>>     No message available. No message is available on the STREAM head
>>>> read queue. [Option End]
>>>> 
>>>> [XSR] [Option Start] XSI STREAMS [Option End]
>>>> The functionality described is optional. The functionality described is
>>>> also an extension to the ISO C standard.
>>>> 
>>>> Where applicable, functions are marked with the XSR margin legend in the
>>>> SYNOPSIS section. Where additional semantics apply to a function, the
>>>> material is identified by use of the XSR margin legend.
>>>> 
>>>> [OB] [Option Start] Obsolescent [Option End]
>>>> The functionality described may be removed in a future version of this
>>>> volume of POSIX.1-2008. Strictly Conforming POSIX Applications and
>>>> Strictly Conforming XSI Applications shall not use obsolescent features.
>>>> 
>>>> Where applicable, the material is identified by use of the OB margin legend.
>>>> ----
>>>> 
>>>> The OB part makes a bit strange to ask for definition, but would it be
>>>> possible to add ENODATA to our headers?
>>>> The alternative question is: why would we not?
>>> 
>>> Well, it's defined for STREAMS and FreeBSD (and BSDs in general) don't
>>> implement STREAMS.  OTOH, if Ceph has (ab)used it for their own internal
>>> errors then we could perhaps add our own ENODATA.  Do you want to make a
>>> patch to do so?
>>> 
>> 
>> Hi John,
>> 
>> Rather old Email, but now it comes to the point that it is going to be
>> used. Uptil now I just patched my onw errno.h, but once I'm going to
>> build a port for Cep, it no long works. I do not think anubody will
>> allow a port to modify /usr/include/errno.h 8-)
>> 
>> For my/Ceph needs the path is rather simple.
>> *** /usr/include/errno.h        Mon Oct  3 02:05:43 2016
>> --- /usr/srcs/head/src/sys/sys/errno.h  Sun Aug 21 18:25:05 2016
>> ***************
>> *** 164,170 ****
>>  #define       ECANCELED       85              /* Operation canceled */
>>  #define       EILSEQ          86              /* Illegal byte sequence */
>>  #define       ENOATTR         87              /* Attribute not found */
>> - #define       ENODATA         87              /* Attribute not found */
>> 
>>  #define       EDOOFUS         88              /* Programming error */
>>  #endif /* _POSIX_SOURCE */
>> --- 164,169 ----
>> 
>> I'll submit this as "bug" report and will see what comes of it.
>> 
>> --WjW
> 
> I too ran into this problem a few years ago.  My solution was to patch
> Ceph instead.  Would these patches still work?
> 
> --- src/include/compat.h.orig   2013-11-01 16:14:01.000000000 +0000
> +++ src/include/compat.h        2013-11-04 18:21:43.000000000 +0000
> @@ -13,7 +13,15 @@
> #define CEPH_COMPAT_H
> 
> #if defined(__FreeBSD__)
> -#define        ENODATA 61
> +/*
> + * FreeBSD does not have ENODATA.  We must define it here.  However, it MAY be
> + * defined by boost.  We can't simply include boost/cerrno.hpp here, because
> + * that header is not includable by C code.  So we must duplicate boost's
> + * definition :(
> + */
> +#ifndef ENODATA
> +#define ENODATA 9919
> +#endif
> #endif /* !__FreeBSD__ */
> 
> #if defined(__FreeBSD__) || defined(__APPLE__)
> --- src/pybind/rados.py.orig    2013-11-04 17:36:06.000000000 +0000
> +++ src/pybind/rados.py 2013-11-04 17:37:02.000000000 +0000
> @@ -89,10 +89,14 @@
>         errno.EIO       : IOError,
>         errno.ENOSPC    : NoSpace,
>         errno.EEXIST    : ObjectExists,
> -        errno.ENODATA   : NoData,
>         errno.EINTR     : InterruptedOrTimeoutError,
>         errno.ETIMEDOUT : TimedOut
>         }
> +    # errno.ENODATA is not implemented on all platforms
> +    try:
> +        errors[errno.ENODATA] = NoData
> +    except AttributeError:
> +        pass
>     ret = abs(ret)
>     if ret in errors:
>         return errors[ret](msg)
> --- src/pybind/cephfs.py.orig   2013-10-10 16:14:07.000000000 +0000
> +++ src/pybind/cephfs.py        2013-10-10 16:15:22.000000000 +0000
> @@ -49,8 +49,12 @@
>         errno.EIO       : IOError,
>         errno.ENOSPC    : NoSpace,
>         errno.EEXIST    : ObjectExists,
> -        errno.ENODATA   : NoData
>         }
> +    # errno.ENODATA is not implemented on all platforms
> +    try:
> +        errors[errno.ENODATA] = NoData
> +    except AttributeError:
> +        pass
>     ret = abs(ret)
>     if ret in errors:
>         return errors[ret](msg)

But it works just the other way around...

There are calls to freebsd xattr() which return ENOATTR on error,
the Linux code however uses ENODATA (in value == 87) to test for errors.
So if anything needs to be defined ENODATA == ENOATTR.
This I do in compat.h but defining it to 9919 would not help.
Stronger, I test for it to not be 9919, or I Error compilation.

And the trouble with all python code is that ignoring ENODATA is not always a wise decision.
Just having it in /usr/include is the right place where python/cython can find it.

And it would help other porting efforts would be helped as well.

--WjW