Yet another post in the series of of C-senior and Rust-junior posts. I also expose this as group therapy sort of influencing reason i.e, perhaps there are kernel devs with some uncertainty when it comes to Rust.Thus, I expose mine :-)
I seem to do this two-step process a lot with Rust:
1. Refine the code for capability and implement that capability.
2. Decouple the capability from the (sub)crate.
E.g., in 0.7.0 I had reworked the whole code base so that lifetime-parameters would be relaxed and finally it was Any-compatible and I had dyn_eq and those shenanigans in the crate.
i.e., straight up the very first commit after tagging:
https://github.com/puavo-org/tpm2_library/commit/c704938ec64d31a1aaa1b88a3f686d5d25045c0bI also felt ultimately stupid as I already had e.g.
pretty_printer.rs that should have "showed me the way". Still I think it was worth it because of all bottlenecks the codebase had with lifetimes that I could not have noticed w/o first going way too far :-)
Pretty printer for reference:
https://github.com/puavo-org/tpm2_library/blob/main/tpm2sh/src/pretty_printer.rsIn my Z-Modem crates next version I'm going to follow the learnings and make it walk and talk like some entity in futures/streams without being coupled to async and of course make it also zero deps:
https://codeberg.org/jarkko/zmodem2/commits/branch/mainI will demonstrate async-ready capability with refined versions of RZM and SZM. Then you can finally have ZModem in your next Tokio project :-)
#linux #rust #kernel