mirror of
https://evilpiepirate.org/git/bcachefs-tools.git
synced 2026-09-10 02:10:35 -04:00
No description
- C 76.5%
- Rust 19.3%
- C++ 2%
- Shell 0.8%
- Makefile 0.7%
- Other 0.7%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
b87c2a19b8
bcachefs's ioctl numbers were computed in Rust, by the generated inventory:
const fn opcode(dir: u32, nr: u32, size: usize) -> u32 {
(dir << 30) | ((size as u32) << 16) | (0xbc << 8) | nr
}
That is asm-generic's _IOC layout, written down. It is correct on x86, arm
and the other asm-generic architectures and wrong everywhere else, so
logan2611's ppc64le sees a filesystem that mounts and then answers ENOTTY
to most ioctls, with the few whose fields happen to line up working by
coincidence (#904, a regression since 1.36).
There is no version of this that can be written down. The kernel has three
separate _IOC() definitions; the size and direction fields have different
widths; _IOC_NONE/READ/WRITE take different values, and parisc's read and
write are the other way round from asm-generic's; sparc deliberately
overlaps the direction and size fields. Even a version parameterised on the
target's _IOC_*SHIFT constants would still be a restatement, and still wrong
on sparc.
So don't restate it. rust_shims.h already had the answer for the block
device ioctls, along with a comment explaining exactly this trap - "an
open-coded 0x127E for BLKROTATIONAL is correct on exactly the architectures
whose _IOC layout you had in mind" - so bind bcachefs's the same way, one
const per ioctl, evaluated by the C compiler against the target's own
<asm/ioctl.h>. Rust gets an integer.
The inventory moves to bch_bindgen with them, since those constants only
exist in this crate's bindings and the fs crate can't see them; nothing in
the kernel build ever used it - the kernel implements ioctls rather than
calling them - so this also stops the DKMS build generating a file it
throws away. The parse that remains reads only the argument type, which is
the one part C can't hand us: bindgen binds values, not types.
The direction bits go with the opcode, and with them the two call-shape
asserts in ioctl_w/ioctl_rw, which compared against literal 1 and 2 - a
third copy of asm-generic's layout, and wrong on the same architectures.
Verified: all 43 opcodes compared against a C program that prints the
macros - no missing bindings, no mismatches - and BCH_IOCTL_QUERY_UUID is
still 0x8010bc01 on x86_64, so nothing changes here.
One trap worth knowing about: bch_bindgen's allowlist_var didn't match the
new names, and bindgen dropped all 43 silently. It surfaced as "cannot find
value in module c", pointing at the use sites rather than the cause.
Reported-by: logan2611
Closes: https://github.com/koverstreet/bcachefs-tools/issues/904
Co-Authored-By: Proof of Concept <poc@bcachefs.org>
Claude-Session: https://claude.ai/code/session_018SHaMsugAT1rz3YcUvvSyn
|
||
| .github | ||
| arch/etc | ||
| bcachefs-shim | ||
| bcachefs-shim-macros | ||
| bch_bindgen | ||
| c_src | ||
| ccan | ||
| debian | ||
| dkms | ||
| doc | ||
| Documentation | ||
| fs | ||
| include | ||
| initramfs | ||
| linux | ||
| package-ci | ||
| raid | ||
| scripts | ||
| signing | ||
| src | ||
| udev | ||
| verus-proofs | ||
| .editorconfig | ||
| .gitignore | ||
| bcachefs | ||
| bcachefs-kmp.spec-preambule | ||
| bcachefs-tools.spec | ||
| bcachefs-wait-devices@.service.in | ||
| bcachefs.8 | ||
| build.rs | ||
| Cargo.lock | ||
| Cargo.toml | ||
| Changelog.mdwn | ||
| CLAUDE.md | ||
| COPYING | ||
| crane-build.nix | ||
| default.nix | ||
| flake.lock | ||
| flake.nix | ||
| INSTALL.md | ||
| make-release-tarball.sh | ||
| Makefile | ||
| Makefile.compiler | ||
| module-build.nix | ||
| mount.bcachefs.sh | ||
| nixos-test.nix | ||
| overlay.nix | ||
| README.md | ||
| rustfmt.toml | ||
bcachefs-tools
Userspace tools and docs for bcachefs
Bcachefs is an advanced new filesystem for Linux, with an emphasis on reliability and robustness and the complete set of features one would expect from a modern filesystem.
This is the official development repository for bcachefs — the userspace
tools, the documentation, and the filesystem source itself. bcachefs is
maintained out of mainline and ships as a DKMS kernel module built from this
tree. To build it into a kernel source tree instead (CONFIG_BCACHEFS_FS),
run scripts/install-to-kernel.sh, which
copies fs/ into <kernel>/fs/bcachefs/ and wires it into the kernel build.
This repo primarily consists of the following:
- bcachefs tool, the reason this repo exists.
- {mkfs,mount,fsck}.bcachefs utils, which is just wrappers calling the corresponding subcommands in the main tool
- docs in the form of man-pages and a user manual
Please refer to the main site for getting started An in-depth user manual is (also) found on the official website
Version semantics
The tools relies on an expected disk format structure which is reflected by your current kernel version. Disk format can be upgraded or downgraded automatically by the kernel, if needed.
- Any patch-level change means no disk format change
- Any minor-level change means a potential disk format change which is not breaking
- Any major-level change means breaking changes
Build and install
Refer to INSTALL.md
Bug reports and contributions
- GitHub issues for bug reports and focused feature requests
- GitHub Discussions for support questions and general usage discussion
- The official mailing list, linux-bcachefs@vger.kernel.org
- IRC: #bcache on OFTC (irc.oftc.net). Note that IRC messages can be easily missed.