Mising ENODATA

Tue Nov 22 23:05:15 UTC 2016

On Tue, Nov 22, 2016 at 3:46 PM, Willem Jan Withagen <wjw at digiware.nl> wrote:
>
>
> 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

If the problem is that Linux's xattr() and FreeBSD's xattr() behave
differently, then the solution should be in the code that uses
xattr(), right?  Something like this:

err = extattr_get_fd(...)
#if defined( freebsd )
if (err == ENOATTR) {
#else if defined (linux)
if (err == ENODATA) {
#endif
    return CEPH_ENODATA
}