glibc: Add f_type to statvfs and statvfs64

[valentynkit]

glibc 2.39 allocated one of the six reserved __f_spare ints to f_type for statvfs and statvfs64, which mirrors statfs.
sailfishos-mirror/glibc@92861d9

Adding f_type to statvfs and statvfs64 for linux/gnu, using c_uint.
Also deduplicated statvfs64 for 32-bit arch, it was declared byte-for-byte identical on six of the eight platforms, so it was moved to the shared b32/mod.rs (m68k and riscv32 differ, so they are excluded by cfg, and keep their own declaration). And deduplicated statvfs and statvfs64 for 64-bit arch, keeping only riscv64 excluded by cfg, and keeping its own declaration.

There is also musl that is missing f_type. It wasn't addressed in this PR, should I address musl also, or any other not just glibc?

Also riscv32 and riscv64 declare their __f_spare field as pub, it feels inconsistent with the other declarations, and for riscv64 it is the reason it keeps its own declaration (riscv32 differs in also lacking __f_unused). Is there a specific reason to have it pub __f_spare, or should this be addressed and fixed?

Closes #4121

Checklist

• Relevant tests in libc-test/semver have been updated, no change needed.
• Commit messages permalink to headers for added or changed API
• No placeholder or unstable values like *LAST or *MAX.
• Tested locally (cargo test -p libc-test --target mytarget); especially relevant for platforms that may not be checked in CI

@rustbot label +stable-nominated

[valentynkit]

Is it okay to have it as one PR, or should dedup in gnu/b32 and gnu/b64 be separate PR?
When I started adding f_type noticed that there were a lot of duplication of identical statvfs and statvfs64, so addressed it in separate commits before adding f_type.

[tgross35]

Any chance you'd be willing to move statvfs* to src/new/glibc/sysdeps/unix/linux first? That would get rid of a ton of duplication. It's a bit tricky but it models the glibc structure and reexports on arches that have an override, see sigaction/signum_arch in https://github.com/rust-lang/libc/blob/2eda1e52fe2efdf93c1e5c65e346343a530d8bc3/src/new/glibc/sysdeps/unix/linux/mod.rs.

Doing this in the same PR is fine as long as it's a separate commit, we use rebase merging.

[tgross35]

I missed a couple of things:

There is also musl that is missing f_type. It wasn't addressed in this PR, should I address musl also, or any other not just glibc?

Mind doing musl in a followup?

Also riscv32 and riscv64 declare their __f_spare field as pub, it feels inconsistent with the other declarations, and for riscv64 it is the reason it keeps its own declaration (riscv32 differs in also lacking __f_unused). Is there a specific reason to have it pub __f_spare, or should this be addressed and fixed?

It's fine to make it non-pub in the deduplication PR, just make sure to note it in the commit message.

Few things here so
@rustbot author

[rustbot]

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