[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-hackers
Subject: Re: Mising ENODATA
From: Willem Jan Withagen <wjw () digiware ! nl>
Date: 2016-11-23 0:08:07
Message-ID: 4fad89b0-cf93-a4df-2164-b5393cb9eea5 () digiware ! nl
[Download RAW message or body]
On 23-11-2016 00:05, Alan Somers wrote:
> On Tue, Nov 22, 2016 at 3:46 PM, Willem Jan Withagen <wjw@digiware.nl> wrote:
>>
>>
>> Op 22 nov. 2016 om 18:32 heeft Alan Somers <asomers@freebsd.org> het volgende geschreven:
>>
>>> On Tue, Nov 22, 2016 at 4:44 AM, Willem Jan Withagen <wjw@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
> }
>
Sure that is a partial solution, but cython needs to be fixed as well.
And that is a lot of place to fix it.
After which there will be LUA problems, or any other interpreter that
gets compiled. And code is again swamped with awkward If-endifs.
ENODATA is currently not really defined, other than for C++ where it is
only defined when it has not been defined in other headers. And then it
gets something that is incompatible with what Linux thinks.
So I think that it is "a good thing" (tm) if this could be part of
errno.h. It might, will, help in other cases as well. Hence my patch, to
me more compatible with Linux. And the standard gives room for that. But
I understand that there a multiple views on the matter.
--WjW
_______________________________________________
freebsd-hackers@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic