From: Florian Weimer <firstname.lastname@example.org>
To: Rich Felker <email@example.com>
Subject: Re: [musl] [PATCH] add statx
Date: Tue, 28 Jan 2020 11:41:33 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <20200124162910.GX30412@brightrain.aerifal.cx> (Rich Felker's message of "Fri, 24 Jan 2020 11:29:10 -0500")
* Rich Felker:
>> >> We received feedback that our headers are not useful due to the
>> >> __u64/uint64_t mismatch.
>> >> <https://sourceware.org/bugzilla/show_bug.cgi?id=25292
>> >> <https://sourceware.org/ml/libc-alpha/2019-12/msg00631.html>
>> > 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-(
> Why not let ppl get the warnings and fix them by casting to an
> appropriate type to print. I prefer [u]intmax_t anyway to avoid the
> PRIu64 etc. mess that makes your format strings unreadable and that
> interferes with translation (*).
I'm concerned that such casts hide or even introduce bugs, like casting
tv_sec to int.
Here's an example from the MySQL sources:
int my_timeval_to_str(const struct timeval *tm, char *to, uint dec)
int len= sprintf(to, "%d", (int) tm->tv_sec);
len+= my_useconds_to_str(to + len, tm->tv_usec, dec);
That's why the kernel always uses unsigned long long for __u64, which
seems a reasonable trade-off to me. It will make porting to 128-bit
architectures difficult. But I think we should focus on the
architectures we have today.
>> > 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.
> I see. This is something of a tradeoff I guess; for musl users I'd
> expect folks to have libc headers newer than kernel headers in most
> cases since distros are slow to follow new kernels but fast to follow
> new libc, and you want compile-time support for future kernel
> features even if you don't have the kernel to use them yet. But on
> glibc-based dists it may be the other way around.
I think it's actually the same for self-built musl on most glibc-based
distributions because for that, developers will usually pick the latest
musl release and use the distribution's kernel headers.
But for glibc itself on glibc distributions, it's likely to have newer
kernel headers. Fedora rebase kernels (including the UAPI headers) in a
release, but not glibc. Debian has backport kernel packages for stable
releases (but no glibc backport). Some enterprise distributions
aggressively backport features (including new userspace APIs) and even
rebase entire kernel subsystems from time to time.
next prev parent reply other threads:[~2020-01-28 10:41 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
2020-01-24 16:29 ` Rich Felker
2020-01-28 10:41 ` Florian Weimer [this message]
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).