Conversation

Jarkko Sakkinen

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/c704938ec64d31a1aaa1b88a3f686d5d25045c0b

I 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.rs

In 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/main

I 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
1
1
3
The current 0.8.0 has the WORST version of object stack representation which is mixed JSON combined with TPM blobs. Seems to still work tho. It's "within migration from json crap" version. 0.9.0 will have that side polished :-)
0
0
0