Compatibility with C PRoot
BoxKernel targets behavioral parity with Termux PRoot 5.1.0 — not just feature parity, but identical observable behavior: same option parsing, same errno paths, same exit statuses, same verbose output shape.
What’s identical
- The entire CLI option set except
--ashmem-memfd(below) - Guest-visible results of translated syscalls — the reference suite validates this end-to-end
- Exit status convention (last terminated program’s status)
-vverbosity levels andnote!severity model- Extension semantics including inheritance (
Kompatshared config,FakeId0per-child) - QEMU
-qcontract: runner resolved on the host,-E/-Uenv pairs emitted in C’s order,/host-rootfsbinding .proot-meta-file.*/.l2s.*helper-file formats — a rootfs written by C proot reads correctly under BoxKernel and vice versaptrace/waitemulation for guest debuggers
Known differences
| Difference | Detail | Status |
|---|---|---|
--ashmem-memfd | Android-only memfd_create-via-ashmem emulation; needs Bionic libandroid-shmem machinery | not ported |
| Internal structure | C’s (callback,config,sysnums) triples → typed Event/AnyExtension | deliberate — same dispatch order |
| Global state | C static vars → atomics/thread_local! | deliberate — same semantics |
| Memory allocation | talloc hierarchy → owned values/Rc/Box | deliberate — C ownership graph preserved |
| Build system | GNU make + libtalloc | Cargo; build.rs runs rustc for loader/ |
| Version string | proot 5.1.0 | BoxKernel 5.1.0 (binary still named proot) |
Things the Rust port does better (and why)
- No libtalloc → fully static-able; the two QEMU-runner suite
tests that fail on the C binary under
unset LD_LIBRARY_PATHpass on ours. - No
static mut, notransmute→ whole classes of memory bugs eliminated rather than audited-around. - Typed extension events → the C
intptr_t data1/data2payloads (whose meaning depended on event type) become structured enums — mismatched-payload bugs are compile errors now. src/sys.rsboundary → a C-identical errno contract is enforced by type, not by convention.
Filing parity bugs
If the Rust binary produces different guest-visible behavior than the C binary for the same command/environment, that’s a parity bug — report it with both outputs:
$ proot-c -v 2 <cmd> 2>c.log
$ proot -v 2 <cmd> 2>rust.log
$ diff -u c.log rust.log
Include the suite test name if a reference test exposes it.