From owner-freebsd-hackers@freebsd.org Mon May 23 22:37:40 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 D4611B47A71 for ; Mon, 23 May 2016 22:37:40 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (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 609E3104A; Mon, 23 May 2016 22:37:39 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id DB6D315340D; Tue, 24 May 2016 00:37:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8HdnNjciopq; Tue, 24 May 2016 00:37:06 +0200 (CEST) Received: from [192.168.10.10] (asus [192.168.10.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 5BCD1153401; Tue, 24 May 2016 00:37:06 +0200 (CEST) Subject: Re: Mising ENODATA To: John Baldwin , freebsd-hackers@freebsd.org References: <56E6C5EA.2080005@digiware.nl> <5030334.fMbvND8flt@ralph.baldwin.cx> From: Willem Jan Withagen Message-ID: Date: Tue, 24 May 2016 00:37:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5030334.fMbvND8flt@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 22:37:40 -0000 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? Well actually I think it is Linux that has found a different purpose for the error value. It uses it as error value where FreeBSD would return ENOATTR.... The actual Linux value is 61, which on FreeBSD would give ECONNREFUSED. Looking at Linux manual pages they write: ENOATTR The named attribute does not exist, or the process has no access to this attribute. (ENOATTR is defined to be a synonym for ENODATA in .) So perhaps for FreeBSD we should do more or less the same, but the other way around? Although on CentOS it is actually in: xfs/linux.h:#define ENOATTR ENODATA /* Attribute not found */ And thus in errno.h include #define ENODATA ENOATTR This would also return the same error string for ENODATA as it would for ENOATTR. Perhaps not quite what was the intention of the Posix extension, but as close as possible to what Linux took it to be. No idea what FreeBSDs position is on this? --WjW Still it does not have the same value as it would on Linux, so over the wire they would still not be compatible. But I think it would work for code that is confined within a host.