`AT_FDCWD` is defined as a macro constant: -100, it works in C… because C.
But in Rust, this will be exposed as a u32 instead of a i32, which is the correct variable type for it.
bcachefs-tools has been using a patched bindgen to work around a
limitation of rustc that prevents compiling structs with
both #[repr(packed(N)] and #[repr(align(N)] attributes. The patch:
e8168ceda507 "codegen: Don't generate conflicting packed() and align()
representation hints." discards the "align" attribute in cases where
bindgen produces a type with both.
This may be correct for some types, but it turns out that for each
bcachefs type with this problem, keeping the "align" attribute and
discarding the "packed" attribute generates a type with the same ABI as
the original C type.
This can be tested automatically by running:
$ cargo test --manifest-path bch_bindgen/Cargo.toml
in the bcachefs-tools tree.
There has been pressure recently to start using upstream bindgen; both
externally, from distribution maintainers who want to build
bcachefs-tools with standard dependencies, and internally, in order to
enable using Rust for bcachefs in-kernel.
This patch updates bcachefs-tools to use upstream bindgen. It works
around the rustc limitation with a post-processing step in the bindgen
build that adjusts the attributes to include "#[repr(C, align(N))]" and
exclude #[repr(packed(N)] only for the 4 types that need it. It also
updates bch_bindgen to format the code with prettyplease so that this
will work even in environments with rustfmt installed.
Some types that had been manually implemented in
bch_bindgen/src/bcachefs.rs are now automatically generated by bindgen,
so that they will be covered by the ABI compatibility testing mentioned
above.
I intentionally targeted the post-processing to the exact 4 types with
the issue currently, so that any changes to bcachefs that result in this
issue appearing for a new type will require manual intervention. I
figured any such changes should require careful consideration.
Ideally, bindgen can be updated to handle situations where "align(N)"
is needed and "packed(N)" can be safely discarded. If a patch for this
is accepted into bindgen, the post-processing hack can be removed.
I update the minimum Rust version to 1.70 as this is needed to build
recent versions of some dependencies.
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
This is redundant with the root level Cargo.lock. Any changes made to
the bch_bindgen dependencies will be duplicated in both Cargo.lock
files. Removing this from version control will reduce the noise in the
git diffs for such changes.
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
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>
When bcachefs was a C program that had some functions implemented in
Rust, it was necessary to make a static library containing the Rust
functions available for the C program to link.
Now that bcachefs is a Rust program, that library is no longer needed.
Instead, the Rust executable links in libbachefs.a.
This patch updates the crate structure to reflect that. The command
functions are moved into their own module.
There could be a need to create a "libbachefs-tools" library in the
future that exposes an API for bcachefs functionality to other
userspace programs. That will be a different, external API as opposed to
the previous library functions which were an internal API for the
bcachefs tool itself.
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
This moves the main() function from C to Rust. It also updates the name
of the Rust package from "bcachefs-rust" to "bcachefs-tools".
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
We're only reading the superblocks, no need for O_EXCL - and this fixes
mounts failing because we're still holding the devices open.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
The only use for itertools is in parse_mount_options() where we take a
vector, convert it to iterator and then join it. Instead, we can join
the vector directly.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
The memmove() in pop_cmd() reads and writes beyond the end of argv.
This is basically harmless in the current C program; the environment
variable list immediately follows argv so all this does is unnecessarily
copy the beginning of that list.
However, this will become problematic once we start calling C functions
like fs_cmds() from Rust code. Then argv will be a Vec<String> (as
*mut *mut i8) and the memory layout will be different--in particular,
I don't think we can assume that a Vec<String> will be NULL-terminated
like argv always is--, meaning the invalid write could lead to heap
corruption.
Also, it doesn't look like full_cmd ever gets used after calling
pop_cmd() so I'm removing it here since it looks unneeded to me.
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
block_size is in bytes, not sectors, so when calling round_up(),
we could start rounding up by a way too large size and then overflow
outside the area that migrate allocated for us.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Correctly generate libexecdir based path for the bcachefsck_all
service, like the bcachefsck_all_fail service already does.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
this gets us back down to a single fd for opening block devices, which
means we can use O_EXCL.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
not needed with pwritev2(.., RWF_SYNC), and perhaps we can get down to
one fd and then use O_EXCL for block devices.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
The bcachefs sub-commands that are implemented in Rust (completions,
list, and mount) had separate entrypoints and thus had some differences
in behavior.
This introduces a common entry point for the Rust sub-commands. This
reduces duplicate boilerplate code like parsing argv and setting up
logging, and will facilitate converting more sub-commands to Rust in
the future.
An immediate benefit is that this fixes an issue with `bcachefs list`
not reporting errors:
before:
$ bcachefs list /dev/typo
$ echo $?
0
after:
$ bcachefs list /dev/typo
ERROR - bcachefs_rust::cmd_list: Fatal error: "No such file or directory"
$ echo $?
1
Signed-off-by: Thomas Bertschinger <tahbertschinger@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
These are executables that need to be installed in a non-path location.
Most distributions now install these into /usr/libexec, and the
path variable for this is LIBEXECDIR, so use that instead.
