TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

A memory model for Rust code in the kernel

114 点作者 jmillikin大约 1 年前

5 条评论

j-krieger大约 1 年前
&gt; He suggested that, perhaps, the kernel&#x27;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.<p>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.<p>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.
PoignardAzur大约 1 年前
&gt; <i>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.</i><p>Okay, that&#x27;s a cheap joke, but it got a chuckle from me.
评论 #39960114 未加载
SloopJon大约 1 年前
I wouldn&#x27;t include atomics and memory barriers in the &quot;fearless concurrency&quot; category of Rust. Is there really a large enough body of third-party code to worry about compatibility?<p>As for Linus&#x27;s complaint that compilers aren&#x27;t perfect, I&#x27;ve seen many bugs over the years with this style of code. A missing memory barrier doesn&#x27;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 &quot;pre-reliable&quot; compiler, where a bug can be fixed once.<p>It seems like they&#x27;re taking a reasonable and measured approach to start with a small surface area, which bodes well for the future of Rust in Linux.
dataflow大约 1 年前
For anyone else also trying to wrap their head around the Clang C++ optimization&#x2F;concurrency bug [1]:<p>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.<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.)<p>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.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;llvm&#x2F;llvm-project&#x2F;issues&#x2F;64188">https:&#x2F;&#x2F;github.com&#x2F;llvm&#x2F;llvm-project&#x2F;issues&#x2F;64188</a>
jart大约 1 年前
It sounds like Torvalds has finally found a way to delay the Rust developers taking over the kernel.