Writing an OS in Rust: Testing
os.phil-opp.com
os.phil-opp.com
[1]: https://os.phil-opp.com/unit-testing/ [2]: https://os.phil-opp.com/integration-tests/
The new test framework directly works with `cargo xtest`, which brings the project closer to using standard cargo programs for building, testing, and running. The last remaining step is the `std` Aware Cargo RFC [3]. When the RFC is merged and implemented, cargo-xbuild will no longer be needed and the familiar cargo build, cargo run, and cargo test commands will just work, including IDE integration.
> I have been trying to hack at the utest crate and get on-device integration tests running again for quite some time... good to know there is movement on the custom test runner front :)
The custom test framework feature of Rust was silently introduced in https://github.com/rust-lang/rust/pull/53410 and I didn't know that it even existed a month ago. But it works really well and seems like a good solution for your problem.
In my mind, what would make rust a fanatic kernel language is tracking allocators with types at the compiler level like it does for Send and Sync.
Other than that, there is ongoing work for custom allocator support in collections: https://github.com/rust-lang/rust/issues/42774. Maybe that's what you meant with tracking the allocators at the type level?
It's of course also possible to create own fallible collection types, for example as a wrapper around the normal liballoc and try_reserve.
[1]: https://doc.rust-lang.org/std/vec/struct.Vec.html#method.try...
I did not write my own stdlib since I didn't need it yet (the blog has no heap allocation yet). And I think infallible allocation is good enough for the beginning.
But I think it should be possible to create a fallible wrapper library around liballoc quite easily. We only need an appropriate call to try_reserve for every wrapped function. For example, `push` would do a `try_reserve(1)` before calling the push function of liballoc.