From owner-freebsd-hackers@freebsd.org Tue Nov 22 23:05:15 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 A99A7C5063A for ; Tue, 22 Nov 2016 23:05:15 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 515271BCF; Tue, 22 Nov 2016 23:05:15 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-qt0-x243.google.com with SMTP id n6so4646856qtd.0; Tue, 22 Nov 2016 15:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZVc0toGG9ZDzsPGtr1s7O2antYd+T6Qx71CNxF/aOKI=; b=1IWg2eKqXQW+1K5cWY/ME1FoHxJcqoeOAj0ZpGqbmXremtYVot8gTzGb8Cw9UK6e4S hP0oBbWno6RpR8uhrVX5O2Rz9ks0X6c2J4hYJgFsasrrbQWj28afziVczZCE7O1iK/eg 7vjWceMpx4z7CItx9YyLye3CRdgWEGZ4pMd/Tj5r82YQkWpTqcNPvzpjBnhkLnAN5Cr4 0As6RS+80C7i68MwhzK2h/NFf/sluaATWa+R1hewTG6yMjTUa5rfGU/Zd8YtI4U7znhB CBnsZMWlsTsUUw4Kr6pbxhUsd/95OA6wHbgJ1X5AED3MVRdcN/jTZREylb4pmc7uMS0k sQeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZVc0toGG9ZDzsPGtr1s7O2antYd+T6Qx71CNxF/aOKI=; b=M56gxcvSH6/QUSGL1Wd9CxEwxlPECk1Sb2/wwEwpVOZwh/V338ibLyfxiOXzfLyeWz 9hE4Mw1UiKRg/YRX0+VZy9gA1EYDPFUVEgdWrFO7wBCiVwqlHMGA5y7t0PEvsUhIqH6/ Tcgo9SZ1BkoIPKQwW0jq3s8MiTz7r6U3vPBai/dPPh2roqEUQiryaGivXX6+z3jsLeSk bC3DtlTUp7dfmUf8tjRdSkdbQ1wBgxjXWncwNBFZdfHNbC5Yk3C+Fg6sl+1Xe2H3DjFN 71RyI8AGWFxDZofDZAV68wplEkNHTjCztQhCyC8u9jK/l3Bc+3CKTlf2aXCtoAo2wsen +7HQ== X-Gm-Message-State: AKaTC03VZQNAd1v1nLe1GWuvtyejQCtYmm7t/H8NvdX04RaMXYmz3S0pIK2N1CAVg21QjmcwKa4B+whYAK9Dpg== X-Received: by 10.200.48.28 with SMTP id f28mr52158qte.247.1479855914119; Tue, 22 Nov 2016 15:05:14 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.12.166.129 with HTTP; Tue, 22 Nov 2016 15:05:13 -0800 (PST) In-Reply-To: <1D7D7363-F503-4322-BBAC-556010E11AF1@digiware.nl> References: <56E6C5EA.2080005@digiware.nl> <5030334.fMbvND8flt@ralph.baldwin.cx> <1D7D7363-F503-4322-BBAC-556010E11AF1@digiware.nl> From: Alan Somers Date: Tue, 22 Nov 2016 16:05:13 -0700 X-Google-Sender-Auth: cImjeloMfAAPOEPWTot0ym8lfYc Message-ID: Subject: Re: Mising ENODATA To: Willem Jan Withagen Cc: John Baldwin , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 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 23:05:15 -0000 On Tue, Nov 22, 2016 at 3:46 PM, Willem Jan Withagen wrote: > > > Op 22 nov. 2016 om 18:32 heeft Alan Somers het volgende geschreven: > >> On Tue, Nov 22, 2016 at 4:44 AM, Willem Jan Withagen 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 }