The second argument to ioctl() can be defined as a different type by
different libc implementations, and can be a different size on different
architectures depending on what type it is defined as. For example,
glibc defines it as `unsigned long` which may have a different size on
32-bit vs. 64-bit architectures, and musl libc defines it as `int`.
The Rust libc crate exposes a type `libc::Ioctl` which is defined as the
appropriate integer type for the given libc implementation. Using this
type for the request argument to `libc::ioctl()` ensures code will
compile correctly regardless of architecture and libc implementation.
Also, because ioctl request numbers are defined to be 32 bits
(regardless of the fact that `unsigned long` might sometimes take 64
bits on some architectures), this patch changes the Rust representation
of the bcachefs ioctl numbers to u32 instead of u64.
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
We propose a simple low-level wrapper which can perform various subvolume-related operations
as an example for the API surface.
This will be used in an upcoming commit to migrate the subvolume CLI fully to Rust.
The API design is the following:
- `BcachefsHandle` is meant as a low level handle to carry around whenever you need a filesystem handle
to send ioctl to.
- it possess type-safe operations
Type safe operations are handled by having type safe wrappers for ioctl commands
*and* their payloads.
We assume that all ioctl payloads only use *one* argument, this can easily be changed if needed.
When the handle goes out of scope, we automatically close it à la C++ RAII.
Signed-off-by: Ryan Lahfa <bcachefs@lahfa.xyz>
This moves the Rust sources out of rust_src/ and into the top level.
Running the bcachefs executable out of the development tree is now:
$ ./target/release/bcachefs command
or
$ cargo run --profile release -- command
instead of "./bcachefs command".
Building and installing is still:
$ make && make install
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
