From owner-freebsd-hackers@freebsd.org Tue Nov 22 22:46:16 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8744C50068 for ; Tue, 22 Nov 2016 22:46:16 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 527701345; Tue, 22 Nov 2016 22:46:16 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id BE1B227BBA; Tue, 22 Nov 2016 23:46:12 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9p8YRkM9U_pB; Tue, 22 Nov 2016 23:46:11 +0100 (CET) Received: from [192.168.10.120] (10G [192.168.10.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 12D1827BB9; Tue, 22 Nov 2016 23:46:11 +0100 (CET) References: <56E6C5EA.2080005@digiware.nl> <5030334.fMbvND8flt@ralph.baldwin.cx> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <1D7D7363-F503-4322-BBAC-556010E11AF1@digiware.nl> Cc: John Baldwin , "freebsd-hackers@freebsd.org" X-Mailer: iPad Mail (9B206) From: Willem Jan Withagen Subject: Re: Mising ENODATA Date: Tue, 22 Nov 2016 23:46:12 +0100 To: Alan Somers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 22:46:16 -0000 Op 22 nov. 2016 om 18:32 heeft Alan Somers het volgend= e geschreven: > On Tue, Nov 22, 2016 at 4:44 AM, Willem Jan Withagen 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