From: "Arnd Bergmann" <arnd@arndb.de>
To: "Antonios Salios" <antonios@mwa.re>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"Deepa Dinamani" <deepa.kernel@gmail.com>
Cc: rydberg@bitmath.org, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, "Jan Henrik Weinstock" <jan@mwa.re>,
"Lukas Jünger" <lukas@mwa.re>
Subject: Re: element sizes in input_event struct on riscv32
Date: Mon, 15 Jan 2024 17:11:50 +0100 [thread overview]
Message-ID: <faf84e13-a927-4679-b837-2509f0209f82@app.fastmail.com> (raw)
In-Reply-To: <20be7b9d5b8c0bef2a35da3d207c15eae75bfd4d.camel@mwa.re>
On Mon, Jan 15, 2024, at 16:46, Antonios Salios wrote:
> On Thu, 2023-12-21 at 14:38 +0100, Antonios Salios wrote:
>> On Thu, 2023-12-21 at 12:28 +0000, Arnd Bergmann wrote:
>> > On Thu, Dec 21, 2023, at 08:56, Antonios Salios wrote:
>> > > On Tue, 2023-12-19 at 13:53 +0000, Arnd Bergmann wrote:
>> > > > On Tue, Dec 19, 2023, at 02:50, Dmitry Torokhov wrote:
>> >
>> > I don't know what __TIMESIZE is, this is not part of the kernel ABI
>> > as far as I can tell. __USE_TIME_BITS64 should be set by any 32-bit
>> > architecture if the C library defines a 64-bit time_t, otherwise
>> > the
>> > kernel headers have no way of picking the correct definitions based
>> > on preprocessor logic.
>>
>> Okay, I agree that this might be a libc problem then. I'll ask the
>> glibc maintainers.
>>
>
> According to a glibc maintainer, __USE_TIME_BITS64 is not set on
> architectures that use 64-bit time_t as default such as riscv32.
> This can also be seen here [1].
>
> Perhaps the kernel header needs to check the size of time_t in some
> other way?
>
> [1]
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/features-time64.h;hb=glibc-2.37
I don't see any better way, the kernel headers started using this
in 2018 based on the glibc design documents and discussions
with glibc maintainers, see the section on ioctls in
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
The kernel only relies on this macro for the sound and
input subsystem, but there are numerous applications and
libraries that copied the kernel definition because that
was defined as the only reliable method.
Maybe you can work around by patching the glibc sources
yourself?
Arnd
prev parent reply other threads:[~2024-01-15 16:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-14 10:11 element sizes in input_event struct on riscv32 Antonios Salios
2023-12-19 2:50 ` Dmitry Torokhov
2023-12-19 13:53 ` Arnd Bergmann
2023-12-21 8:56 ` Antonios Salios
2023-12-21 12:28 ` Arnd Bergmann
2023-12-21 13:38 ` Antonios Salios
2024-01-15 15:46 ` Antonios Salios
2024-01-15 16:11 ` Arnd Bergmann [this message]
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=faf84e13-a927-4679-b837-2509f0209f82@app.fastmail.com \
--to=arnd@arndb.de \
--cc=antonios@mwa.re \
--cc=deepa.kernel@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=jan@mwa.re \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas@mwa.re \
--cc=rydberg@bitmath.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
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).