linux: Use the input_event_X macros to access input_event members

[snogge]

Description

Use the input_event_sec and input_event_usec members (macros in C) on all platforms, no matter whether time_t is 32 or 64 bits.
This means the same members are available in the struct no matter whether it is a 32 or 64 bit platform or the linux_time_bits64 config is set.

This is a breaking change.

Sources

https://github.com/torvalds/linux/blob/0cc53520e68bea7fb80fdc6bdf8d226d1b6a98d9/include/uapi/linux/input.h#L28

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget);
  especially relevant for platforms that may not be checked in CI

This is a breaking change and should not be backported to the 0.2 branch.

[tgross35]

I'm sorry this has taken me forever to come to consensus on, but I do now think this is the right approach. I have a couple of non-technical requests, the code changes LGTM.

[tgross35]

I would like to backport this part of the change. It is technically breaking but our definition is incorrect without it, and sparc64 isn't all that popular of a target. Would you be able to split this to a separate commit?

Padding fields should also get wrapped in Padding<...> now

[tgross35]

Hm - actually, I think this change may not be correct on its own. Looks like the __usec/input_event_usec field would also need to be changed from a long to an int https://github.com/torvalds/linux/blob/3f9f0252130e7dd60d41be0802bf58f6471c691d/include/uapi/linux/input.h#L35C6-L42.

We should probably do that change still to make sure users don't expect the upper half of that field to work, just annoying that sparc has a special-cased suseconds_t in the first place.

(context: torvalds/linux@2e74694)

[tgross35]

Nevermind, I see now that the field is of type suseconds_t. Sorry for the confusion; please disregard everything in this thread except for the Padding<...> bit.

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[snogge]

I've seen your comments and hope to get around to this next week.

[snogge]

@rustbot ready

@tgross35 The change causes CI errors for i686-linux-unknown-musl. I was not sure what the right thing to do was - I have not been keeping up to date on changes - so I added another time64 exception for musl.

[tgross35]

The musl time64 changes caused a conflict here so this will need a rebase (sorry about that)

@tgross35 The change causes CI errors for i686-linux-unknown-musl. I was not sure what the right thing to do was - I have not been keeping up to date on changes - so I added another time64 exception for musl.

I think it should be fixed by #4463 which resolved everything else in that block (hence the conflict), musl on relevant platforms should be setting the linux time64 cfg now.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[snogge]

Rebase is done, I think the failing check is unrelated.

@rustbot ready