原文
From: Greg KH <[email protected]> To: Boqun Feng <[email protected]> Cc: "H. Peter Anvin" <[email protected]>, Miguel Ojeda <[email protected]>, Christoph Hellwig <[email protected]>, rust-for-linux <[email protected]>, Linus Torvalds <[email protected]>, David Airlie <[email protected]>, [email protected], [email protected] Subject: Re: Rust kernel policy Date: Wed, 19 Feb 2025 06:39:10 +0100 [thread overview] Message-ID: <2025021954-flaccid-pucker-f7d9@gregkh> (raw) In-Reply-To: <[email protected]> On Tue, Feb 18, 2025 at 07:04:59PM -0800, Boqun Feng wrote: > On Tue, Feb 18, 2025 at 04:58:27PM -0800, H. Peter Anvin wrote: > [...] > > > > David Howells did a patch set in 2018 (I believe) to clean up the C code in the kernel so it could be compiled with either C or C++; the patchset wasn't particularly big and mostly mechanical in nature, something that would be impossible with Rust. Even without moving away from the common subset of C and C++ we would immediately gain things like type safe linkage. > > > > > > That is great, but that does not give you memory safety and everyone > > > would still need to learn C++. > > > > The point is that C++ is a superset of C, and we would use a subset of C++ > > that is more "C+"-style. That is, most changes would occur in header files, > > especially early on. Since the kernel uses a *lot* of inlines and macros, > > the improvements would still affect most of the *existing* kernel code, > > something you simply can't do with Rust. > > > > I don't think that's the point of introducing a new language, the > problem we are trying to resolve is when writing a driver or some kernel > component, due to the complexity, memory safety issues (and other > issues) are likely to happen. So using a language providing type safety > can help that. Replacing inlines and macros with neat template tricks is > not the point, at least from what I can tell, inlines and macros are not > the main source of bugs (or are they any source of bugs in production?). > Maybe you have an example? As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years (well hopefully all of them end up in the stable trees, we do miss some at times when maintainers/developers forget to mark them as bugfixes), and who sees EVERY kernel CVE issued, I think I can speak on this topic. 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.) I'm all for moving our C codebase toward making these types of problems impossible to hit, the work that Kees and Gustavo and others are doing here is wonderful and totally needed, we have 30 million lines of C code that isn't going anywhere any year soon. That's a worthy effort and is not going to stop and should not stop no matter what. But for new code / drivers, writing them in rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this? C++ isn't going to give us any of that any decade soon, and the C++ language committee issues seem to be pointing out that everyone better be abandoning that language as soon as possible if they wish to have any codebase that can be maintained for any length of time. Rust also gives us the ability to define our in-kernel apis in ways that make them almost impossible to get wrong when using them. We have way too many difficult/tricky apis that require way too much maintainer review just to "ensure that you got this right" that is a combination of both how our apis have evolved over the years (how many different ways can you use a 'struct cdev' in a safe way?) and how C doesn't allow us to express apis in a way that makes them easier/safer to use. Forcing us maintainers of these apis to rethink them is a GOOD thing, as it is causing us to clean them up for EVERYONE, C users included already, making Linux better overall. And yes, the Rust bindings look like magic to me in places, someone with very little Rust experience, but I'm willing to learn and work with the developers who have stepped up to help out here. To not want to learn and change based on new evidence (see my point about reading every kernel bug we have.) 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? Linux is a tool that everyone else uses to solve their problems, and here we have developers that are saying "hey, our problem is that we want to write code for our hardware that just can't have all of these types of bugs automatically". Why would we ignore that? Yes, I understand our overworked maintainer problem (being one of these people myself), but here we have people actually doing the work! Yes, mixed language codebases are rough, and hard to maintain, but we are kernel developers dammit, we've been maintaining and strengthening Linux for longer than anyone ever thought was going to be possible. We've turned our development model into a well-oiled engineering marvel creating something that no one else has ever been able to accomplish. Adding another language really shouldn't be a problem, we've handled much worse things in the past and we shouldn't give up now on wanting to ensure that our project succeeds for the next 20+ years. We've got to keep pushing forward when confronted with new good ideas, and embrace the people offering to join us in actually doing the work to help make sure that we all succeed together. thanks, greg k-h
next prev parent reply other threads:[~2025-02-19 5:39 UTC|newest] Thread overview: 178+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-02-09 20:56 Rust kernel policy Miguel Ojeda 2025-02-18 16:08 ` Christoph Hellwig 2025-02-18 16:35 ` Jarkko Sakkinen 2025-02-18 16:39 ` Jarkko Sakkinen 2025-02-18 18:08 ` Jarkko Sakkinen 2025-02-18 21:22 ` Boqun Feng 2025-02-19 6:20 ` Jarkko Sakkinen 2025-02-19 6:35 ` Dave Airlie 2025-02-19 11:37 ` Jarkko Sakkinen 2025-02-19 13:25 ` Geert Uytterhoeven 2025-02-19 13:40 ` Jarkko Sakkinen 2025-02-19 7:05 ` Boqun Feng 2025-02-19 11:32 ` Jarkko Sakkinen 2025-02-18 17:36 ` Jiri Kosina 2025-02-20 6:33 ` Christoph Hellwig 2025-02-20 18:40 ` Alexei Starovoitov 2025-02-18 18:46 ` Miguel Ojeda 2025-02-18 21:49 ` H. Peter Anvin 2025-02-18 22:38 ` Dave Airlie 2025-02-18 22:54 ` Miguel Ojeda 2025-02-19 0:58 ` H. Peter Anvin 2025-02-19 3:04 ` Boqun Feng 2025-02-19 5:07 ` NeilBrown 2025-02-19 5:39 ` Greg KH [this message] 2025-02-19 15:05 ` Laurent Pinchart 2025-02-20 20:49 ` Lyude Paul 2025-02-21 19:24 ` Laurent Pinchart 2025-02-20 7:03 ` Martin Uecker 2025-02-20 7:10 ` Greg KH 2025-02-20 8:57 ` Martin Uecker 2025-02-20 13:46 ` Dan Carpenter 2025-02-20 14:09 ` Martin Uecker 2025-02-20 14:38 ` H. Peter Anvin 2025-02-20 15:25 ` Dan Carpenter 2025-02-20 15:49 ` Willy Tarreau 2025-02-22 15:30 ` Kent Overstreet 2025-02-20 14:53 ` Greg KH 2025-02-20 15:40 ` Martin Uecker 2025-02-21 0:46 ` Miguel Ojeda 2025-02-21 9:48 ` Dan Carpenter 2025-02-21 16:28 ` Martin Uecker 2025-02-21 17:43 ` Steven Rostedt 2025-02-21 18:07 ` Linus Torvalds 2025-02-21 18:19 ` Steven Rostedt 2025-02-21 18:31 ` Martin Uecker 2025-02-21 19:30 ` Linus Torvalds 2025-02-21 19:59 ` Martin Uecker 2025-02-21 20:11 ` Linus Torvalds 2025-02-22 7:20 ` Martin Uecker 2025-02-21 22:24 ` Steven Rostedt 2025-02-21 23:04 ` Linus Torvalds 2025-02-22 17:53 ` Kent Overstreet 2025-02-22 18:44 ` Linus Torvalds 2025-02-23 16:42 ` David Laight 2025-02-22 18:42 ` Linus Torvalds 2025-02-22 9:45 ` Dan Carpenter 2025-02-22 10:25 ` Martin Uecker 2025-02-22 11:07 ` Greg KH 2025-02-21 18:23 ` Martin Uecker 2025-02-21 22:14 ` Steven Rostedt 2025-02-21 18:11 ` Theodore Ts'o 2025-02-24 8:12 ` Dan Carpenter 2025-02-20 22:08 ` Paul E. McKenney 2025-02-22 23:42 ` Piotr Masłowski 2025-02-23 8:10 ` Martin Uecker 2025-02-23 23:31 ` comex 2025-02-24 9:08 ` Ventura Jack 2025-02-24 18:03 ` Martin Uecker 2025-02-20 12:28 ` Jan Engelhardt 2025-02-20 12:37 ` Greg KH 2025-02-20 13:23 ` H. Peter Anvin 2025-02-20 13:51 ` Willy Tarreau 2025-02-20 15:17 ` C aggregate passing (Rust kernel policy) Jan Engelhardt 2025-02-20 16:46 ` Linus Torvalds 2025-02-20 20:34 ` H. Peter Anvin 2025-02-21 8:31 ` HUANG Zhaobin 2025-02-21 18:34 ` David Laight 2025-02-21 19:12 ` Linus Torvalds 2025-02-21 20:07 ` comex 2025-02-21 21:45 ` David Laight 2025-02-22 6:32 ` Willy Tarreau 2025-02-22 6:37 ` Willy Tarreau 2025-02-22 8:41 ` David Laight 2025-02-22 9:11 ` Willy Tarreau 2025-02-21 20:06 ` Jan Engelhardt 2025-02-21 20:23 ` Laurent Pinchart 2025-02-21 20:24 ` Laurent Pinchart 2025-02-21 22:02 ` David Laight 2025-02-21 22:13 ` Bart Van Assche 2025-02-22 5:56 ` comex 2025-02-21 20:26 ` Linus Torvalds 2025-02-20 22:13 ` Rust kernel policy Paul E. McKenney 2025-02-21 5:19 ` Felipe Contreras 2025-02-21 5:36 ` Boqun Feng 2025-02-21 5:59 ` Felipe Contreras 2025-02-21 7:04 ` Dave Airlie 2025-02-24 20:27 ` Felipe Contreras 2025-02-24 20:37 ` Boqun Feng 2025-02-26 2:42 ` Felipe Contreras 2025-02-22 16:04 ` Kent Overstreet 2025-02-22 17:10 ` Ventura Jack 2025-02-22 17:34 ` Kent Overstreet 2025-02-23 2:08 ` Bart Van Assche 2025-02-19 5:53 ` Alexey Dobriyan 2025-02-19 5:59 ` Dave Airlie 2025-02-22 18:46 ` Kent Overstreet 2025-02-19 12:37 ` Miguel Ojeda 2025-02-20 11:26 ` Askar Safin 2025-02-20 12:33 ` vpotach 2025-02-19 18:52 ` Kees Cook 2025-02-19 19:08 ` Steven Rostedt 2025-02-19 19:17 ` Kees Cook 2025-02-19 20:27 ` Jason Gunthorpe 2025-02-19 20:46 ` Steven Rostedt 2025-02-19 20:52 ` Bart Van Assche 2025-02-19 21:07 ` Steven Rostedt 2025-02-20 16:05 ` Jason Gunthorpe 2025-02-20 8:13 ` Jarkko Sakkinen 2025-02-20 8:16 ` Jarkko Sakkinen 2025-02-20 11:57 ` Fiona Behrens 2025-02-20 14:07 ` Jarkko Sakkinen 2025-02-21 10:19 ` Jarkko Sakkinen 2025-02-22 12:10 ` Miguel Ojeda 2025-02-20 9:55 ` Leon Romanovsky 2025-02-19 19:33 ` H. Peter Anvin 2025-02-20 6:32 ` Alexey Dobriyan 2025-02-20 6:53 ` Greg KH 2025-02-20 8:44 ` Alexey Dobriyan 2025-02-20 13:53 ` Willy Tarreau 2025-02-20 16:04 ` Jason Gunthorpe 2025-02-20 12:01 ` H. Peter Anvin 2025-02-20 12:13 ` H. Peter Anvin 2025-02-20 23:42 ` Miguel Ojeda 2025-02-22 15:21 ` Kent Overstreet 2025-02-20 6:42 ` Christoph Hellwig 2025-02-20 23:44 ` Miguel Ojeda 2025-02-21 15:24 ` Simona Vetter 2025-02-22 12:10 ` Miguel Ojeda 2025-02-26 13:17 ` Fiona Behrens 2025-02-21 0:39 ` Linus Torvalds 2025-02-21 12:16 ` Danilo Krummrich 2025-02-21 15:59 ` Steven Rostedt 2025-02-23 18:03 ` Laurent Pinchart 2025-02-23 18:31 ` Linus Torvalds 2025-02-26 16:05 ` Jason Gunthorpe 2025-02-26 19:32 ` Linus Torvalds 2025-02-19 8:05 ` Dan Carpenter 2025-02-19 14:14 ` James Bottomley 2025-02-19 14:30 ` Geert Uytterhoeven 2025-02-19 14:46 ` Martin K. Petersen 2025-02-19 14:51 ` Bartosz Golaszewski 2025-02-19 15:15 ` James Bottomley 2025-02-19 15:33 ` Willy Tarreau 2025-02-19 15:45 ` Laurent Pinchart 2025-02-19 15:46 ` James Bottomley 2025-02-19 15:56 ` Willy Tarreau 2025-02-19 16:07 ` Laurent Pinchart 2025-02-19 16:15 ` Willy Tarreau 2025-02-19 16:32 ` Laurent Pinchart 2025-02-19 16:34 ` Willy Tarreau 2025-02-19 16:33 ` Steven Rostedt 2025-02-19 16:47 ` Andrew Lunn 2025-02-19 18:22 ` Jarkko Sakkinen 2025-02-20 6:26 ` Alexey Dobriyan 2025-02-20 15:37 ` Steven Rostedt 2025-02-19 17:00 ` Martin K. Petersen 2025-02-19 15:13 ` Steven Rostedt 2025-02-19 14:05 ` James Bottomley 2025-02-19 15:08 ` Miguel Ojeda 2025-02-19 16:03 ` James Bottomley 2025-02-19 16:44 ` Miguel Ojeda 2025-02-19 17:06 ` Theodore Ts'o 2025-02-20 23:40 ` Miguel Ojeda 2025-02-22 15:03 ` Kent Overstreet 2025-02-20 16:03 ` James Bottomley 2025-02-20 23:47 ` Miguel Ojeda 2025-02-20 6:48 ` Christoph Hellwig 2025-02-20 12:56 ` James Bottomley
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=2025021954-flaccid-pucker-f7d9@gregkh \ [email protected] \ [email protected] \ [email protected] \ [email protected] \ [email protected] \ [email protected] \ [email protected] \ [email protected] \ [email protected] \ [email protected] \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).