From: Florian Weimer <email@example.com>
To: Rich Felker <firstname.lastname@example.org>
Subject: Re: [musl] [PATCH] add statx
Date: Fri, 24 Jan 2020 17:12:51 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
In-Reply-To: <20200124155458.GW30412@brightrain.aerifal.cx> (Rich Felker's message of "Fri, 24 Jan 2020 10:54:58 -0500")
* Rich Felker:
> 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.
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.
> 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
next prev parent reply other threads:[~2020-01-24 16:13 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-19 12:12 Ben Noordhuis
2020-01-24 8:38 ` [musl] " Ben Noordhuis
2020-01-24 14:01 ` Rich Felker
2020-01-28 8:59 ` Ben Noordhuis
2020-01-28 13:39 ` Rich Felker
2020-01-24 14:00 ` [musl] " Rich Felker
2020-01-24 15:27 ` Florian Weimer
2020-01-24 15:54 ` Rich Felker
2020-01-24 16:12 ` Florian Weimer [this message]
2020-01-24 16:29 ` Rich Felker
2020-01-28 10:41 ` Florian Weimer
2020-01-28 13:18 ` Rich Felker
2020-02-17 9:10 ` Florian Weimer
2020-02-17 15:29 ` Rich Felker
2022-08-27 14:57 ` [musl] [PATCH 0/1] " Duncan Bellamy
2022-08-27 14:57 ` [musl] [PATCH 1/1] resubmitting old statx patch with changes Duncan Bellamy
2022-08-27 18:10 ` Rich Felker
2022-08-27 23:11 ` Dunk
2022-08-27 23:11 ` [musl] [PATCH 0/2] V2 Duncan Bellamy
2022-08-27 23:11 ` [musl] [PATCH 1/2] V2 resubmitting old statx patch with changes Duncan Bellamy
2022-08-29 13:50 ` [musl] " Dunk
2022-08-27 23:11 ` [musl] [PATCH 2/2] V2 src/stat/fstatat.c use new statx define Duncan Bellamy
2022-08-31 19:07 ` [musl] [PATCH 0/2] V3 Duncan Bellamy
2022-08-31 19:07 ` [musl] [PATCH 1/2] V3 resubmitting old statx patch with changes Duncan Bellamy
2022-08-31 19:07 ` [musl] [PATCH 2/2] V3 src/stat/fstatat.c use new statx define Duncan Bellamy
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).