[HN Gopher] A memory model for Rust code in the kernel
___________________________________________________________________
A memory model for Rust code in the kernel
Author : jmillikin
Score : 92 points
Date : 2024-04-06 04:42 UTC (1 days ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| PoignardAzur wrote:
| > _Without that caching, performance would slow to a crawl,
| severely impacting the production, delivery, and consumption of
| cat videos, phishing spam, and cryptocurrency scams. This
| prospect is seen as a bad thing._
|
| Okay, that's a cheap joke, but it got a chuckle from me.
| bru3s wrote:
| Very reminiscent of Adam Douglas' writing style (or Terry
| Pratchett FWIW)
| gostsamo wrote:
| > This prospect is seen as a bad thing.
|
| This is almost word for word lifted from The Hitchhiker's
| Guide to the Galaxy.
| zellyn wrote:
| Should that be Galaxy's Guide to the Hitchhiker, by Adam
| Douglas?
| bru3s wrote:
| I reckon it's more likely to have come out of World of
| Disks, by Pratchy Terriett
| raphlinus wrote:
| To me it recalls "This has made a lot of people very
| angry and has been widely regarded as a bad move," which
| is a bit from the introduction and first chapter of the
| Hitchhiker's Guide.
| gostsamo wrote:
| Yep, this is the quote.
| dataflow wrote:
| For anyone else also trying to wrap their head around the Clang
| C++ optimization/concurrency bug [1]:
|
| The crux of it is that deleting *p = i prior to foo(i, a) is
| illegal, because it would lose the guarantee that *a == N implies
| *p == N in another thread, when X == p.
|
| (i.e. After the optimization, it becomes possible for other
| threads to observe *p != N even when *a == N, but this should be
| impossible according to the original code.)
|
| The general issue is that loop invariant code motion (LICM)
| optimization would also be required to hoist out any threading-
| related guarantees (like memory fences) from loops, not just the
| data as it appears to a single thread.
|
| [1] https://github.com/llvm/llvm-project/issues/64188
| j-krieger wrote:
| > He suggested that, perhaps, the kernel's memory model could be
| rebuilt on top of C or C++ atomic operations, at which point
| supporting the Rust model would be easier. That seems unlikely to
| happen, though, given the strong opposition from Linus Torvalds
| to any such change.
|
| Torvalds is right on this issue. I'm an avid rust fan and use the
| language every day. Rust has the job to adapt to the kernel, not
| the other way around. Imagine if instead on working on ,,panic-
| free" rust for the kernel, maintainers would call for the kernel
| to just crash.
|
| If rust can not sufficiently adapt to the way of the kernel,
| either the language needs to change or the experiment needs to be
| considered as a failed one.
| jart wrote:
| It sounds like Torvalds has finally found a way to delay the Rust
| developers taking over the kernel.
| SloopJon wrote:
| I wouldn't include atomics and memory barriers in the "fearless
| concurrency" category of Rust. Is there really a large enough
| body of third-party code to worry about compatibility?
|
| As for Linus's complaint that compilers aren't perfect, I've seen
| many bugs over the years with this style of code. A missing
| memory barrier doesn't exactly stand out. Maybe Linux has a
| better track record, but I would love to push as much of this as
| possible into the hands of a "pre-reliable" compiler, where a bug
| can be fixed once.
|
| It seems like they're taking a reasonable and measured approach
| to start with a small surface area, which bodes well for the
| future of Rust in Linux.
___________________________________________________________________
(page generated 2024-04-07 23:02 UTC)