linux_like: Unify statx definitions by neuschaefer · Pull Request #3978 · rust-lang/libc

neuschaefer · 2024-10-16T17:31:15Z

Description

The statx system call and corresponding constants are defined by the Linux kernel and don't depend on the libc or architecture. The only difference is whether a libc exports the statx syscall wrapper or not.

We can thus unify the statx definitions for all Linux "like" platforms: GNU (glibc), Android (bionic), and (in a later commit) musl.

The statx struct is in a separate file because the style check doesn't allow multiple s! macros in one file, and #[cfg()] doesn't work in s!.

Plain u64 (or uint64_t in C) can't be used for the statx fields because bionic defines them as __u64, and provides incompatible definitions of uint64_t and __u64.

Sources

none

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 (failed due to unrelated error, linux/errqueue.h)

rustbot · 2024-10-16T17:31:20Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @JohnTitor (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

@rustbot author: the review is finished, PR author should check the comments and take action accordingly
@rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

tgross35 · 2024-11-06T18:58:36Z

+ mod linux_statx;
+ pub use self::linux_statx::*;


This looks fine to me, but could you inline the definitions here rather than creating an API-specific module?

I tried, but I wasn't able to use s! and apply cfg! conditions. Maybe there's some trick that I missed, but otherwise, I'd leave it for a later refactoring, if at all.

Hm, what exactly is the error? This should work okay, see e.g.
libc/src/unix/linux_like/linux/mod.rs
Lines 1041 to 1043 in c3bc406
cfg_if!{
if #[cfg(not(target_arch = "sparc64"))]{
s!{

@tgross35 not sure what I previously did wrong, but it seems to work now. I'll update the PR, thanks!

Ah, the problems are back, the style check isn't happy:
src/unix/linux_like/mod.rs:1892: constant found after extern function when it belongs before src/unix/linux_like/mod.rs:1933: struct found after constant when it belongs before src/unix/linux_like/mod.rs:1933: multiple s! macros in one module

I wound up disabling that multiple s! check because it's kind of false-positive-y, so this should be good with a rebase after #4107 lands (~1 hour)
Sorry for all the conflicts, been doing a lot of branch cleanup work.

@tgross35 thanks a lot!

However, the other two ordering errors still occur. Perhaps I could move the constants/structs to the other constants/structs. Should I try that?

It is required that things are ordered typedefs->types->functions->consts, it looks like your cfg_if block is reversed.
It it still complains after you correct the ordering, I think you might just need to split into three invocations of cfg_if! and sort it with the rest of the file.

tgross35 · 2024-11-06T18:58:52Z

Also cc @maurer regarding android changes

tgross35 · 2024-11-06T21:35:03Z

@rustbot author for the above.

Just comment @rustbot review once changed

neuschaefer · 2024-11-07T14:31:38Z

Thanks for reviewing!

@rustbot review

maurer · 2024-11-13T19:09:47Z

Unifying this should be fine, as our statx definition in Android is directly derived from kernel headers.

There are also at least four new members on this struct, but they ate the padding so what's written here is still right.

neuschaefer · 2024-11-13T22:34:45Z

While I'm at it, I am also rebasing onto main.

bors · 2024-11-18T13:29:15Z

☔ The latest upstream changes (presumably #4094) made this pull request unmergeable. Please resolve the merge conflicts.

The statx system call and corresponding constants are defined by the Linux kernel and don't depend on the libc or architecture. The only difference is whether a libc exports the statx syscall wrapper or not. We can thus unify the statx definitions for all Linux "like" platforms: GNU (glibc), Android (bionic), and (in a later commit) musl. Plain u64 (or uint64_t in C) can't be used for the statx fields because bionic defines them as __u64, and provides incompatible definitions of uint64_t and __u64.

neuschaefer · 2024-11-22T22:44:51Z

@rustbot review

neuschaefer · 2024-11-23T19:52:34Z

Hmm,

"test_tier2": {
"result": "cancelled",
"outputs": {}
},

apparently that's what lead to this PR getting kicked out of the merge queue

tgross35 · 2024-11-24T00:21:39Z

Probably a timeout, sometimes the android jobs get stuck. You can see the relevant run under “view details” where GH says it removed from the queue.

Added it back.

The statx system call and corresponding constants are defined by the Linux kernel and don't depend on the libc or architecture. The only difference is whether a libc exports the statx syscall wrapper or not. We can thus unify the statx definitions for all Linux "like" platforms: GNU (glibc), Android (bionic), and (in a later commit) musl. Plain u64 (or uint64_t in C) can't be used for the statx fields because bionic defines them as __u64, and provides incompatible definitions of uint64_t and __u64. (backport <rust-lang#3978>) (cherry picked from commit e46bbe4)

Summary: [#3978](rust-lang/libc#3978) introduced the error bellow: ``` error[E0451]: field `__statx_timestamp_pad1` of struct `statx_timestamp` is private --> fbcode/hermetic_infra/reverie/reverie-syscalls/src/args/time.rs:56:13 | 56 | __statx_timestamp_pad1: [0], | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ private field error: aborting due to 1 previous error ``` Removing `From` impl since it does not appear to be used anywhere. Reviewed By: zertosh Differential Revision: D68680975 fbshipit-source-id: f54cb2e2cf1b6a03cda8b8427a7709a2793f2c67

rustbot assigned JohnTitor Oct 16, 2024

rustbot added the S-waiting-on-review label Oct 16, 2024

neuschaefer mentioned this pull request Oct 16, 2024
Enable statx on musl-libc #3976
Merged
3 tasks

tgross35 reviewed Nov 6, 2024
View reviewed changes

tgross35 added the stable-nominated This PR should be considered for cherry-pick to libc's stable release branch label Nov 6, 2024

rustbot added S-waiting-on-author and removed S-waiting-on-review labels Nov 6, 2024

rustbot added S-waiting-on-review and removed S-waiting-on-author labels Nov 7, 2024

neuschaefer force-pushed the statx-unify branch from c3bc406 to 2bec769Compare November 13, 2024 22:28

rustbot added O-android O-gnu O-linux O-linux-like O-unix O-wasm labels Nov 13, 2024

neuschaefer force-pushed the statx-unify branch from 2bec769 to 5e9dc4eCompare November 13, 2024 22:34

tgross35 removed the O-wasm label Nov 14, 2024

neuschaefer force-pushed the statx-unify branch from 5e9dc4e to 6bdc655Compare November 19, 2024 00:28

tgross35 added S-waiting-on-author and removed S-waiting-on-review labels Nov 19, 2024

neuschaefer force-pushed the statx-unify branch from 6bdc655 to f333c2aCompare November 19, 2024 16:27

neuschaefer force-pushed the statx-unify branch from f333c2a to e46bbe4Compare November 22, 2024 22:28

rustbot added S-waiting-on-review and removed S-waiting-on-author labels Nov 22, 2024

tgross35 approved these changes Nov 23, 2024
View reviewed changes

tgross35 added this pull request to the merge queue Nov 23, 2024

github-merge-queueBot removed this pull request from the merge queue due to failed status checks Nov 23, 2024

tgross35 added this pull request to the merge queue Nov 24, 2024

Merged via the queue into rust-lang:main with commit 57b620bNov 24, 2024

This was referenced Nov 24, 2024
Fix the definition of sigevent on FreeBSD and Linux #3630
Merged
Migrate to Rust edition 2021 #4132
Merged

neuschaefer deleted the statx-unify branch November 24, 2024 01:46

This was referenced Nov 25, 2024
[0.2] Backports #4139
Merged
[0.2] Backports #4142
Merged

tgross35 added stable-applied This PR has been cherry-picked to libc's stable release branch and removed stable-nominated This PR should be considered for cherry-pick to libc's stable release branch labels Nov 25, 2024

Uh oh!

Conversation

neuschaefer commented Oct 16, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Sources

Checklist

Uh oh!

rustbot commented Oct 16, 2024

Uh oh!

tgross35Nov 6, 2024

Choose a reason for hiding this comment

Uh oh!

neuschaeferNov 7, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35Nov 13, 2024

Choose a reason for hiding this comment

Uh oh!

neuschaeferNov 13, 2024

Choose a reason for hiding this comment

Uh oh!

neuschaeferNov 13, 2024

Choose a reason for hiding this comment

Uh oh!

tgross35Nov 19, 2024

Choose a reason for hiding this comment

Uh oh!

neuschaeferNov 19, 2024

Choose a reason for hiding this comment

Uh oh!

neuschaeferNov 19, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35Nov 19, 2024

Choose a reason for hiding this comment

Uh oh!

tgross35 commented Nov 6, 2024

Uh oh!

tgross35 commented Nov 6, 2024

Uh oh!

neuschaefer commented Nov 7, 2024

Uh oh!

maurer commented Nov 13, 2024

Uh oh!

neuschaefer commented Nov 13, 2024

Uh oh!

bors commented Nov 18, 2024

Uh oh!

neuschaefer commented Nov 22, 2024

Uh oh!

Uh oh!

neuschaefer commented Nov 23, 2024

Uh oh!

tgross35 commented Nov 24, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

neuschaefer commented Oct 16, 2024•
edited
Loading

neuschaeferNov 7, 2024•
edited
Loading

neuschaeferNov 19, 2024•
edited
Loading