[HN Gopher] How to write Rust in the Linux kernel: part 3
___________________________________________________________________
How to write Rust in the Linux kernel: part 3
Author : chmaynard
Score : 251 points
Date : 2025-07-18 22:27 UTC (1 days ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| mmastrac wrote:
| As a "userspace" Rust developer, I'm happy that this still
| appears to be close enough to the standard Rust dialect that I
| could still be productive. I suspect that allocations are
| intentionally a little more explicit.
|
| It would be cool if there was a few easy-for-beginner tasks to
| pick up and try my hand at this sort of work.
| tialaramex wrote:
| A big eventual non-technical goal of the Rust for Linux project
| is to reduce the barrier to entry for kernel programming, Rust
| is a good language for averting gumption traps IMO +
|
| + https://en.wiktionary.org/wiki/gumption_trap
| spease wrote:
| Yeah, Rust tends to have enough type-safety that you can encode
| project-specific constraints to it and lower the learning curve
| to that of Rust itself, rather than learning all the
| idiosyncratic unconscious and undocumented design constraints
| that you need to abide by to keep from destabilizing things.
| biorach wrote:
| Nicely put
| a5c11 wrote:
| [flagged]
| steveklabnik wrote:
| Rust was _also_ made specifically for the purpose of writing
| code like this.
|
| Nobody is trying to "push and shape a favorite tool." Take it
| from greg-kh:
|
| https://lore.kernel.org/rust-for-linux/2025021954-flaccid-pu...
|
| > The majority of bugs (quantity, not quality/severity) we have
| are due to the stupid little corner cases in C that are totally
| gone in Rust. Things like simple overwrites of memory (not that
| rust can catch all of these by far), error path cleanups,
| forgetting to check error values, and use-after-free mistakes.
| That's why I'm wanting to see Rust get into the kernel, these
| types of issues just go away, allowing developers and
| maintainers more time to focus on the REAL bugs that happen
| (i.e. logic issues, race conditions, etc.)
|
| > Rust isn't a "silver bullet" that will solve all of our
| problems, but it sure will help in a huge number of places, so
| for new stuff going forward, why wouldn't we want that?
| a5c11 wrote:
| I had my journey of using Rust to implement a WinAPI-based
| app in which I did lots of unsafe (from Rust's point of view)
| operations. I spent more time on fighting with Rust's
| protections than on the actual implementation. The result
| code wasn't safe and looked horrible - totally opposite of
| what Rust code should look like. And yes, I followed "the
| Rust way" of doing things.
|
| As much as I really like the mechanics of Rust and the
| language itself, I don't think I'm gonna use it for any of
| the device drivers I'm working on.
|
| The problems you have quoted are due to developers being
| sloppy. I've gone through hundreds of source codes in Kernel,
| and most of them wouldn't pass code review in my company -
| cutting-corners everywhere, multipurpose functions, lack of
| documentation; those are issues which can't be fixed by just
| changing a language. Sure it will protect developers from
| missing "free()" here and there, but it's gonna bite from
| another side.
| randint01 wrote:
| when you say "i did lots of unsafe operations", i think it
| contractions the claim that you "followed the rust way of
| doing things". what's the point of using a "memory-safe"
| language if you just gonna use unsafe blocks and ignore
| that? i agree with you point that there's some operations
| that rust sucks and c is a better option although. but my
| claim is that writing unsafe rust and safe are diferent
| things, for example they created a book talking just about
| unsafe rust -> https://doc.rust-lang.org/nomicon/
| spease wrote:
| > I had my journey of using Rust to implement a WinAPI-
| based app in which I did lots of unsafe (from Rust's point
| of view) operations. I spent more time on fighting with
| Rust's protections than on the actual implementation. The
| result code wasn't safe and looked horrible - totally
| opposite of what Rust code should look like. And yes, I
| followed "the Rust way" of doing things.
|
| I hate to just directly question your last statement, but
| "tons of unsafe" is a red flag that the way things are
| being done. You should need it for direct interactions with
| a C API, or for the lowest level of interacting with bare
| metal memory registers, or for lowest level high
| performance code that's verging on or actually using
| assembly.
|
| I can see how doing windows API stuff would cause a lot of
| the FFI usage of unsafe, but that should be handled by the
| winapi or a windows api crate that converts things to
| idiomatic rust and the rest of the codebase would be
| dealing with logic.
|
| Entirely possible you hit an edge case here where you were
| writing glue code which exclusively talked to hand-
| optimized SSE algorithms or something, but that is
| exceedingly rare compared to someone just starting out
| who's experienced with C trying to do things the C way and
| fighting through unsafe rather than looking for and finding
| higher-level patterns that are idiomatic.
|
| > I've gone through hundreds of source codes in Kernel, and
| most of them wouldn't pass code review in my company -
| cutting-corners everywhere, multipurpose functions, lack of
| documentation; those are issues which can't be fixed by
| just changing a language.
|
| Except they are mitigated to such a degree that it again
| makes me doubt you were coding idiomatically.
|
| Rust tends to force you to exhaustively handle code paths,
| so it will require a lot of explicit opting out to cut
| corners.
|
| Type-safety tends to help _a lot_ in making multipurpose
| functions self-verifying. Function chains come up a lot
| more in Rust and type inference works so well because of
| this.
|
| Documentation is a lot easier when you can just have people
| use "cargo doc" and add a bit of markdown and some doctests
| that will get exercised by CI.
|
| > Sure it will protect developers from missing "free()"
| here and there, but it's gonna bite from another side.
|
| RAII is the smallest difference in DX in Rust compared to
| working in C. For me the biggest differences were tooling,
| and type-safety making it a lot easier to catch bugs at
| compile-time, and enforce design assumptions I had about
| the architecture.
|
| I don't necessarily expect it to be easier to write Rust
| code, but I do expect it will catch more issues up-front
| rather than at runtime or in the field, so you will end up
| doing more code-compile iterations (seconds to minutes) and
| fewer code-customer iterations (hours to days or weeks).
|
| Though when it comes to C++, there is less surface area of
| the language to learn to get to the modern "safe"
| constructs and the constructs enforce their own proper
| usage rather than expecting the developer to, so I expect
| an intermediate developer to be writing better code until a
| C++ developer gets to an expert level.
| kstrauser wrote:
| I agree with you there. Rust lets me spend my remaining
| brain cycles considering the logic and flow of my code,
| not worrying that I screwed up memory handling and such.
| jcranmer wrote:
| We have literal decades of experience showing that the
| problem isn't "get good"--no matter how many best practices
| are followed, it turns out that the next generation of
| fuzzers or analyzers or whatnot is able to uncover yet more
| problems in the most perfect codebases we're aware of.
|
| In my experience--and most others' too--it is far better to
| design APIs so that they are _impossible_ to misuse, rather
| than relying on developers to remember the rules to prevent
| misuse. This is where maxims like "parse, don't validate"
| come from. C's type system is simply too weak for API
| misuse to be made compile-time failures, which means you
| have to rely on convention, and anyone who thinks that
| convention can be made robust across a multimillion line
| codebase is delusional. One of the advantages of Rust is
| that you can create newtypes which rewrap the APIs to make
| misuse impossible. I've been working on some numerics code
| in Rust, and the first thing I did was to make different
| types for the different kinds of indices (rows, columns,
| permuted rows, etc.) so that it's simply impossible to use
| the wrong index for a given array.
|
| Also, one of those things I've noticed is that most of the
| people who are dismissive of Rust is that they point to its
| protection against 'missing "free()" here and there.' Which
| is strange, because it probably doesn't even make the top
| 10 list of problems in C that Rust protects against. The C
| issue that keeps me up at night when I write C code is
| pointer invalidation, which is what Rust's lifetimes +
| mutability xor aliasibility rules are meant to protect
| against. So why talk about free and not pointer
| invalidation?
| Ar-Curunir wrote:
| There is not one group of developers C folks won't throw
| under the bus (eg by calling them sloppy) to defend C.
|
| Like here you have one of the lead devs of the Linux kernel
| saying that Rust solves many problems that he has seen
| happen repeatedly in the kernel, and you're saying "hm well
| they must just have been sloppy".
| cmrdporcupine wrote:
| Yep.
|
| Frankly there is a whole subsection of our profession
| which is composed of engineers who have differentiated
| themselves on their elite skills with difficult low-level
| languages, and if you pry that cultural marker away from
| them, they get defensive.
|
| I see this in C/C++ forums all the time: "Rust doesn't
| solve a problem _I_ have ". Actually, yes it does. They
| might not think it, but I've been in enough codebases
| over the years by some very skilled C & C++ programmers
| to know better. The mistakes are preventable by a decent
| modern language that doesn't let you just null and leak
| all over the place in entirely preventable ways.
|
| Rust has all sorts of problems, it's definitely not
| perfect. It is not the final form for systems programming
| languages.
|
| But it's getting tiresome to see people who won't admit
| that the C legacy is a real problem at this point. And
| it's not like it (lack of safety, rigour, etc.) wasn't
| known along the way (or Ada would never have been a
| thing, etc.) -- it just wasn't considered important.
|
| Well it should be now. Hell, in the _kernel_ in
| privileged execution space more than _anywhere_ else it
| is most important.
| iknowstuff wrote:
| > And yes, I followed "the Rust way" of doing things.
|
| Alright show up buddy, let us code review
| MangoToupe wrote:
| C really _wasn 't_ designed to handle common low-level hurdles
| any more than the CPUs that created the problems were. Just
| because you can formulate solutions doesn't mean shooting
| yourself in the foot isn't easier.
| cmrdporcupine wrote:
| Applying the phrase "designed" to C is already dubious. It's
| a language that _evolved_ from a very minimal and not
| terribly "designed" thing based off predecessor languages
| whose primary selling point was basically "it's easier to
| write a compiler for than Algol"
|
| I don't _hate_ C, but we can do a lot better with hindsight
| and at this point the amount of damage caused by foisting
| null terminated strings on the world is inexcusable.
| tester756 wrote:
| How much experience you have with: C, Rust and Kernel
| development?
| a5c11 wrote:
| Can't count in years because for my 9-5 work I use different
| languages. I started learning C when I was 15, now I'm over
| 30, and it constantly appears somewhere in my life, whether
| this is embedded or desktop development. Kernel -
| occasionally, when I must adapt or implement a device driver.
| Rust - I had three approaches, all of them related to WinAPI-
| based programs, but didn't suit my needs. I like it, I will
| come back to it at some point for sure, but definitely not in
| the context of Kernel.
|
| You wanna hire me?
| dang wrote:
| " _Eschew flamebait. Avoid generic tangents._ "
|
| " _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._"
|
| https://news.ycombinator.com/newsguidelines.html
___________________________________________________________________
(page generated 2025-07-19 23:01 UTC)