Re: element sizes in input_event struct on riscv32

[Arnd Bergmann]

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