Rust tutorial via mailing list

Posted Feb 10, 2025 21:51 UTC (Mon) by intelfx (subscriber, #130118)
In reply to: Rust tutorial via mailing list by raven667
Parent article: Maintainer opinions on Rust-for-Linux

There is *a lot* of high-quality educational material on Rust on the Internet. Linux kernel maintainers, especially the veteran ones (who seem to have the most trouble with Rust so far, incidentally or not), are typically regarded as a pretty autonomous and self-sufficient bunch. If they wanted, they would've.

Rust tutorial via mailing list

Posted Feb 11, 2025 8:53 UTC (Tue) by edomaur (subscriber, #14520) [Link]

I love that one (it helped me) : https://fasterthanli.me/articles/a-half-hour-to-learn-rust

Rust tutorial via mailing list

Posted Feb 11, 2025 17:52 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

I don't think people are that simple, especially busy people, sure in theory they could all independently research and find high quality Rust tutorial content targeted toward the OS kernel maintainer instead of the application developer, but their brains are made of meat, all the way through, and providing some vetted guidance, meeting them *more* than halfway, is probably what it takes to be effective, not over-interpreting the fact one might not have familiarized themselves with Rust yet as hard evidence that they will refuse.

Rust tutorial via mailing list

Posted Feb 11, 2025 21:39 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (2 responses)

Existing tutorials are not great for learning Rust in the specific context of kernel development. An ideal Rust-for-Linux tutorial should do many things that no existing Rust tutorial does:

* It should assume deep familiarity with C in general, and kernel C in particular. Don't explain what a pointer is or why UAF is a bad thing.
* The "getting started" section should probably just be a copy or alias of https://docs.kernel.org/rust/quick-start.html. The rest of the tutorial should be written assuming that those steps have been done and that (e.g.) all R4L unstable features are enabled and the compiler is not going to complain about them.
* It should not demonstrate any API that would never be used in (most) kernel code. Do not demonstrate how to use std::boxed::Box, because std is not linked into R4L. Instead, if a Box is to be explained at all, it should show how to use kernel::alloc::kbox::Box, which has a different API.
* It should not hide behind the 'nomicon. Unsafe code should get a proper tutorial of its own, preferably as a continuation of the main tutorial. It should not be handwaved as "too hard" or "you won't need it," because anyone doing Rust-C FFI absolutely will need to use unsafe in certain places, and those are the exact places where maintainers will be expected to look when changing C APIs.

Rust tutorial via mailing list

Posted Feb 12, 2025 5:33 UTC (Wed) by mcon147 (subscriber, #56569) [Link]

This seems like really good educational material, for new rust kernel contributors regardless of if they are a maintainer

Rust tutorial via mailing list

Posted Feb 12, 2025 7:27 UTC (Wed) by johill (subscriber, #25196) [Link]

Arguably, that's the "intro to rust as a Linux developer" version; of course you never claimed otherwise.

For maintainers, I'd really like to see more coverage along the lines of what you described over in the typestate comment just now, because I think that's critical for designing the correct APIs for use within the kernel (or any bigger application). Not that I could do it, I have barely enough exposure to the ideas (and rust code) to maybe think it'd be a good idea.

(However, one of the first things I was envisioning being able to ensure with rust in a kernel context would, I believe, require true linear types, so having all the information should probably come with a description of the boundaries too.)