[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 3 Mar 2024 10:17:19 -0500
From: Rich Felker <dalias@...c.org>
To: Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Cc: busybox@...ybox.net, musl@...ts.openwall.com,
Waldemar Brodkorb <wbx@...nadk.org>
Subject: Re: Busybox hwclock failing to build with musl RISC-V 32-bit:
SYS_settimeofday undefined
On Sun, Mar 03, 2024 at 03:36:11PM +0100, Thomas Petazzoni wrote:
> Hello,
>
> The recently released musl 1.2.5 includes 32-bit RISC-V support. Turns
> out that building Busybox 1.36.1 with this new musl version, on 32-bit
> RISC-V, fails with:
>
> util-linux/hwclock.c: In function 'set_kernel_tz':
> util-linux/hwclock.c:142:27: error: 'SYS_settimeofday' undeclared (first use in this function); did you mean 'xsettimeofday'?
> 142 | int ret = syscall(SYS_settimeofday, NULL, tz);
> | ^~~~~~~~~~~~~~~~
> | xsettimeofday
> util-linux/hwclock.c:142:27: note: each undeclared identifier is reported only once for each function it appears in
>
> Busybox already includes some slightly convoluted sorcery to deal with
> musl:
>
> static void set_kernel_tz(const struct timezone *tz)
> {
> #if LIBC_IS_MUSL
> /* musl libc does not pass tz argument to syscall
> * because "it's deprecated by POSIX, therefore it's fine
> * if we gratuitously break stuff" :(
> */
> #if !defined(SYS_settimeofday) && defined(SYS_settimeofday_time32)
> # define SYS_settimeofday SYS_settimeofday_time32
> #endif
> int ret = syscall(SYS_settimeofday, NULL, tz);
> #else
> int ret = settimeofday(NULL, tz);
> #endif
> if (ret)
> bb_simple_perror_msg_and_die("settimeofday");
> }
>
> I am not sure whether this is a Busybox problem or a musl problem,
> which is why I'm cross-posting on both mailing lists.
>
> Thanks a lot in advance for your feedback,
It was broken by this commit which is completely wrong:
https://git.busybox.net/busybox/commit/util-linux/hwclock.c?id=9e262f13c2e53490d69d3112ffd718c27de04d1f
Especially the comment about the reason musl does not do this is
wrong. It's very intentional that we do not pass this to the kernel.
musl is not a GNU/Linux clone. I've been through this with Toybox
folks too, where there's a more detailed explanation in this PR
thread:
https://github.com/landley/toybox/pull/479
Since it's invasive enough to be hard to carry a revert, just revert
the first hunk (wrong detection for musl) and the rest will become a
no-op.
As a Busybox *user*, I deem the change in this patch actively hostile.
If a musl-based system, which has always been designed *not to use*
kernel-timezone functionality that breaks fatfs timestamps and does
other harmful things, suddenly started setting it at boot because of a
new patch to Busybox, and thereby corrupted my data, I would be rather
infuriated.
If Busybox really wants to do this, they need to figure out how to do
it on archs that do not have SYS_settimeofday (such as riscv32). That
was a problem for glibc too when they did their time64 stuff. Because
musl has never supported this behavior, we had nothing to do to fix it
for time64. But if they stick with this, distros are going to need to
carry a patch to patch it out, so that users' timestamps don't get
messed up.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
