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=-2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 450535f8 for ; Fri, 24 Jan 2020 16:13:12 +0000 (UTC) Received: (qmail 5175 invoked by uid 550); 24 Jan 2020 16:13:10 -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 5154 invoked from network); 24 Jan 2020 16:13:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579882378; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MS/DmP9yJDK+FNWgm+6mhSnRxePwxM4EjFXb9WJlieA=; b=OvaPG6hgmg3ULYihdEid//lZafAyNHqDtGmR8MqZUMrUNnj4QdKNf9dHY55xFYOyhCY1xk gqzzOMrOvOHSUFCGwHfWxqurcJKERXKh5AHH2pfC4R6sQVixbBeasgUbggORtsv8UF4hNp 2aBaBySzEYqGlB5Co/1gEqlSmcginBc= From: Florian Weimer To: Rich Felker Cc: musl@lists.openwall.com References: <20200119121247.37310-1-info@bnoordhuis.nl> <20200124140027.GT30412@brightrain.aerifal.cx> <878slw3mdo.fsf@oldenburg2.str.redhat.com> <20200124155458.GW30412@brightrain.aerifal.cx> Date: Fri, 24 Jan 2020 17:12:51 +0100 In-Reply-To: <20200124155458.GW30412@brightrain.aerifal.cx> (Rich Felker's message of "Fri, 24 Jan 2020 10:54:58 -0500") Message-ID: <87k15g25q4.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-MC-Unique: XKrsB7i2OGSqGEderXYOAQ-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [PATCH] add statx * Rich Felker: > On Fri, Jan 24, 2020 at 04:27:47PM +0100, Florian Weimer wrote: >> * Rich Felker: >>=20 >> > 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. >>=20 >> 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. Sorry for nit-picking, it's common to both GNU and Linux. gettid is Linux-specific, and so is pthread_getattr_default_np. pkey_set is something that is GNU/Linux-specific in the sense that is something that's only part of glibc, and only on Linux. >> We received feedback that our headers are not useful due to the >> __u64/uint64_t mismatch. >>=20 >> > > > 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? Yes, printf format strings. 8-( > 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. I thought so too, which is why I used them. But it is fairly compelling to use the kernel types if the header is available, so that we don't have to patch and rebuild glibc if someone backports new statx features into the kernel. That's why I added the __has_include kludge. Thanks, Florian