Date: Tue, 22 Nov 2016 23:46:12 +0100 From: Willem Jan Withagen <wjw@digiware.nl> To: Alan Somers <asomers@freebsd.org> Cc: John Baldwin <jhb@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Mising ENODATA Message-ID: <1D7D7363-F503-4322-BBAC-556010E11AF1@digiware.nl> In-Reply-To: <CAOtMX2ikiVtMwZ-ADqyA=eupbSUX8Ovjb35=b_wg7w2ZF6hUfg@mail.gmail.com> References: <56E6C5EA.2080005@digiware.nl> <5030334.fMbvND8flt@ralph.baldwin.cx> <a423fa87-f5f4-23fe-d7c7-ac60c1dabe90@digiware.nl> <CAOtMX2ikiVtMwZ-ADqyA=eupbSUX8Ovjb35=b_wg7w2ZF6hUfg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Op 22 nov. 2016 om 18:32 heeft Alan Somers <asomers@freebsd.org> het volgend= e geschreven: > On Tue, Nov 22, 2016 at 4:44 AM, Willem Jan Withagen <wjw@digiware.nl> wro= te: >> On 23-5-2016 22:47, John Baldwin wrote: >>> On Monday, March 14, 2016 03:08:42 PM Willem Jan Withagen wrote: >>>> Hi, >>>>=20 >>>> According the standard is ENODATA an extention of errno.h defines... >>>>=20 >>>> http://pubs.opengroup.org/onlinepubs/9699919799/ >>>>=20 >>>> The Open Group Base Specifications Issue 7 >>>> IEEE Std 1003.1, 2013 Edition >>>>=20 >>>> [ENODATA] >>>> [OB XSR] [Option Start] >>>> No message available. No message is available on the STREAM head >>>> read queue. [Option End] >>>>=20 >>>> [XSR] [Option Start] XSI STREAMS [Option End] >>>> The functionality described is optional. The functionality described is= >>>> also an extension to the ISO C standard. >>>>=20 >>>> Where applicable, functions are marked with the XSR margin legend in th= e >>>> SYNOPSIS section. Where additional semantics apply to a function, the >>>> material is identified by use of the XSR margin legend. >>>>=20 >>>> [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= . >>>>=20 >>>> Where applicable, the material is identified by use of the OB margin le= gend. >>>> ---- >>>>=20 >>>> 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? >>>=20 >>> 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? >>>=20 >>=20 >> Hi John, >>=20 >> 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-) >>=20 >> 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 */= >>=20 >> #define EDOOFUS 88 /* Programming error */ >> #endif /* _POSIX_SOURCE */ >> --- 164,169 ---- >>=20 >> I'll submit this as "bug" report and will see what comes of it. >>=20 >> --WjW >=20 > I too ran into this problem a few years ago. My solution was to patch > Ceph instead. Would these patches still work? >=20 > --- 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 >=20 > #if defined(__FreeBSD__) > -#define ENODATA 61 > +/* > + * FreeBSD does not have ENODATA. We must define it here. However, it M= AY be > + * defined by boost. We can't simply include boost/cerrno.hpp here, beca= use > + * that header is not includable by C code. So we must duplicate boost's= > + * definition :( > + */ > +#ifndef ENODATA > +#define ENODATA 9919 > +#endif > #endif /* !__FreeBSD__ */ >=20 > #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] =3D NoData > + except AttributeError: > + pass > ret =3D 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] =3D NoData > + except AttributeError: > + pass > ret =3D 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 =3D=3D 87) to test for errors.= So if anything needs to be defined ENODATA =3D=3D 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 fi= nd it. And it would help other porting efforts would be helped as well. --WjW
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1D7D7363-F503-4322-BBAC-556010E11AF1>