bytecodealliance / bytecodealliance/rustix
About `statfs.f_fsid`
- Dominant language
- Rust
- Stars
- 2.1k
- Forks
- 294
- Avg merge
- 4h 7m
- Merged PRs (30d)
- 2
Description
`statfs` in rustix 0.38 returned the raw linux-raw-sys `statfs64` struct. rustix 1.0 changed this to a rustix `StatFs` struct that uses a `Fsid` struct for the `f_fsid` field. For the `libc` backend this is a alias to `libc::fsid_t`, the `linux_raw` backend defines the `Fsid` struct by itself.
The problem is that this struct is completely useless. Although this is also (kind of) true at the kernel level:
> Nobody knows what `f_fsid` is supposed to contain (but see below).
, the situation in rustix is even more useless.
While you can not be rely on the meaning and ABI of `f_fsid` across different operating systems, you can use it within one operating system where it has the same meaning and ABI. However this is not really possible with rustix because there are no methods to access the value or do basic operations on it like compare for equality.
Ideas on getting out of this:
- derive `PartialEq` in `linux_raw` (for `libc` backend this is already derived if `extra_traits` is used) to support comparing of two `Fsid` instances.
- This does not fix the problem that you can not create a `Fsid` without `transmute_copy` (which should be same because of `repr(C)` with `Copy`).
- add a function to expose "the raw value" (for all(?) operating systems "the raw value" can be transmuted to an `u64`?).
- Likely impossible for `libc` backend without `transmute(_copy)`.
Contributor guide
Assessment
This issue has not been assessed yet.