From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 1c9b9e84 for ; Fri, 24 Jan 2020 15:55:14 +0000 (UTC) Received: (qmail 31959 invoked by uid 550); 24 Jan 2020 15:55:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 31941 invoked from network); 24 Jan 2020 15:55:12 -0000 Date: Fri, 24 Jan 2020 10:54:58 -0500 From: Rich Felker To: Florian Weimer Cc: musl@lists.openwall.com Message-ID: <20200124155458.GW30412@brightrain.aerifal.cx> References: <20200119121247.37310-1-info@bnoordhuis.nl> <20200124140027.GT30412@brightrain.aerifal.cx> <878slw3mdo.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878slw3mdo.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] [PATCH] add statx On Fri, Jan 24, 2020 at 04:27:47PM +0100, Florian Weimer wrote: > * Rich Felker: > > > This is under BSD||GNU (i.e. DEFAULT||ALL) rather than just under the > > latter. Is there a reason for that? Generally the extensions that are > > pretty clearly Linux-only, as opposed to something that other > > POSIX-based OS's are likely to adopt, are put under GNU/ALL to > > discourage their use without intent and to avoid namespace clutter. > > statx is not Linux-specific in glibc, but also available on Hurd. OK, well GNU/Linux-specific. :-) Some ppl find _GNU_SOURCE odd for stuff that comes from Linux not GNU, but in this case it seems pretty appropriate since GNU and Linux are the two systems doing it. > We received feedback that our headers are not useful due to the > __u64/uint64_t mismatch. > > Uhg. That change seems unfortunate since it's incompatible with theoretical future archs having 128-bit long long -- an idea I'm not much a fan of, but don't actually want to preclude. Is there a reason to actually care about compatibility with the kernel types? It's not like both struct definitions can be included in the same source anyway; the tags would clash. Using the canonical uintN_t types makes more sense from an API perspective, I think; kernel assumptions about types should not leak into an API intended to be clean and shared with non-Linux implementations. Rich