Rustaceans at the border [LWN.net]

Rustaceans at the border

Posted Apr 14, 2022 20:29 UTC (Thu) by djc (subscriber, #56880)
In reply to: Rustaceans at the border by mb
Parent article: Rustaceans at the border

Keeping the Cargo.lock file in the Git repository is pretty common for Rust applications, we do that at work.

I don't see the point in Rust for Linux forbidding the use of crates.io crates. Yes, you'd probably want to enforce that only no_std crates are pulled in (I don't know if that's currently supported), but otherwise it seems like a great way of sharing functionality with other parts of the ecosystem.

I can see how pulling in an async runtime would be a bigger deal, but at the same time being able to write async code instead of callback hell seems like it might be important for making code easier to understand the same way it does in userspace.

to post comments

Rustaceans at the border

Posted Apr 14, 2022 22:48 UTC (Thu) by ssokolow (guest, #94568) [Link]

Keeping the Cargo.lock file in the Git repository is pretty common for Rust applications, we do that at work.

I think it'd be more likely they'd want to use cargo vendor (which automatically vendors the specified dependencies) so the kernel repository can use third-party crates but rely on crates.io only as a means of standardizing/automating the rote steps in their existing workflow for manually OKing updates to vendored dependencies.

I can see how pulling in an async runtime would be a bigger deal, but at the same time being able to write async code instead of callback hell seems like it might be important for making code easier to understand the same way it does in userspace.

They'd almost certainly want to write their own executor which is just an API adapter for the relevant kernel machinery.

That's the whole point of Rust's async system being designed as it is. To avoid tying everyone to a single executor.

(Yeah, most people use tokio because the APIs provided beyond the executor itself are still working toward standardization, but those are generally std things like userspace I/O anyway, so that's not relevant to kernel or embedded use-cases.)