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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Supporting Linux kernel development in Rust

648 点作者 dochtman超过 4 年前

14 条评论

jasonhansel超过 4 年前
I&#x27;m concerned about the gradual move from GCC to LLVM. The lack of copyleft protections on LLVM means that it&#x27;s much more dependent on corporate sponsorship, and means that there&#x27;s a risk that major improvements to LLVM compilers will only become available as proprietary products.<p>People underestimate the role of copyleft licenses in preserving long-running FOSS products like GCC, Linux, etc.
评论 #24337796 未加载
评论 #24338425 未加载
评论 #24337515 未加载
评论 #24337844 未加载
评论 #24338187 未加载
评论 #24340700 未加载
评论 #24337451 未加载
评论 #24338963 未加载
评论 #24339782 未加载
cbmuser超过 4 年前
If we get the Rust backend for gcc finalized and merged first, it would be much easier to get Rust code into the kernel:<p>&gt; <a href="https:&#x2F;&#x2F;github.com&#x2F;philberty&#x2F;gccrs&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;philberty&#x2F;gccrs&#x2F;</a>
评论 #24336462 未加载
评论 #24342293 未加载
puzzledobserver超过 4 年前
One of the challenges to building an entirely new kernel is the vast amount of hardware support in the form of drivers and the features the existing kernel exports to userland in the form of syscalls.<p>Would it be possible for a hypothetical new kernel, presumably written in Rust, to run an existing kernel such as Linux in a VM, just to tap into its drivers and emulate its syscalls? As more drivers are ported to the base kernel, the reliance on the donor kernel would shrink over time.<p>Edit: This was an aside. Of course I realize that the conference was about adding Rust code to the Linux kernel, and not about rewriting any large, important, and functional codebase in language-of-the-day™. Hence my speculative language: &quot;hypothetical&quot; new kernel, &quot;presumably&quot; written in Rust.
评论 #24335809 未加载
评论 #24335786 未加载
评论 #24337220 未加载
评论 #24335689 未加载
评论 #24337356 未加载
评论 #24338038 未加载
评论 #24339482 未加载
评论 #24336032 未加载
评论 #24335838 未加载
评论 #24336524 未加载
评论 #24336218 未加载
ogoffart超过 4 年前
&gt; The ubiquitous kmalloc() function, for instance, is defined as __always_inline, meaning that it is inlined into all of its callers and no kmalloc() symbol exists in the kernel symbol table for Rust to link against. This problem can be easily worked around — one can define a kmalloc_for_rust() symbol containing an un-inlined version but performing these workarounds by hand would result in a large amount of manual work and duplicated code.<p>That&#x27;s why there exists crates like <a href="https:&#x2F;&#x2F;docs.rs&#x2F;cpp&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.rs&#x2F;cpp&#x2F;</a> which allow to embed C++ (and thus C) directly into the rust source code, simplifying the manual work and reducing the duplicated code.
评论 #24336754 未加载
nielsbot超过 4 年前
Sounds like they have the same problem Apple&#x27;s Swift does for calling into C&#x2F;Obj-C.<p>Two examples: My understanding is that there&#x27;s a ton of code and added complexity in Swift itself to support Obj-C interoperation. And while you can call C and Obj-C APIs, as-is, there was&#x2F;is basically a company-wide effort to write API wrappers (aka. overlays) for existing system APIs.<p>For the second part, maybe if Rust for Linux kernel programming gets to the level of popularity as, say, TypeScript in the JavaScript community, the Linux community will end up creating the needed API wrappers as an organic, group effort.
评论 #24339003 未加载
评论 #24339186 未加载
aey超过 4 年前
We built a whole BPF tool chain for rust :), although not for kernel development.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;solana-labs&#x2F;rust" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;solana-labs&#x2F;rust</a><p>If this kind of seems interesting please send us a CV.
评论 #24340343 未加载
评论 #24339483 未加载
boogies超过 4 年前
Probably a crazy unpopular opinion, but I kind of agree with the Hyperbola (GNU &#x2F; formerly Linux-libre, in future using a fork of the OpenBSD kernel <a href="https:&#x2F;&#x2F;itsfoss.com&#x2F;hyperbola-linux-bsd&#x2F;" rel="nofollow">https:&#x2F;&#x2F;itsfoss.com&#x2F;hyperbola-linux-bsd&#x2F;</a>) devs that Rust in Linux is not necessarily a good thing, for the reasons they mentioned when they announced they were switching kernels (<a href="https:&#x2F;&#x2F;www.hyperbola.info&#x2F;news&#x2F;announcing-hyperbolabsd-roadmap&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.hyperbola.info&#x2F;news&#x2F;announcing-hyperbolabsd-road...</a>) (Edit: and the LLVM dependency).
评论 #24335708 未加载
评论 #24335599 未加载
评论 #24335729 未加载
评论 #24335582 未加载
评论 #24335752 未加载
评论 #24335639 未加载
评论 #24335800 未加载
Thaxll超过 4 年前
Looks like there is a lot of work involved to have anything done, remind me the issues that the Chrome team said 2 weeks ago.
评论 #24335772 未加载
评论 #24335783 未加载
评论 #24335687 未加载
ghostwriter超过 4 年前
I won&#x27;t get tired of repeating the same comment in every topic that suggests Rust to be a great replacement of C in <i>existing projects</i>, that it isn&#x27;t.<p>The safety guarantees that Rust provides are neither unique nor complete, and if we discuss the amount of effort necessary for bringing new interfaces like the one this article mentions (&quot;one can define a kmalloc_for_rust() symbol containing an un-inlined version&quot;), we should compare it to other existing solutions, like ATS [1], that are designed to be seamlessly interoperable with C codebases without giving up on the safety side of the argument.<p>Just a week ago there was a link in ATS reddit channel that advertised ATS Linux [2][3] initiative, that may be of great interest for the same people who are interested in bringing more memory sefety to Kernel development, without giving up on existing C interfaces and the toolchain[4].<p>[1] <a href="http:&#x2F;&#x2F;www.ats-lang.org&#x2F;Documents.html#INT2PROGINATS" rel="nofollow">http:&#x2F;&#x2F;www.ats-lang.org&#x2F;Documents.html#INT2PROGINATS</a><p>[2] <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;ATS&#x2F;comments&#x2F;ibyczp&#x2F;ats_linux&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;ATS&#x2F;comments&#x2F;ibyczp&#x2F;ats_linux&#x2F;</a><p>[3] <a href="http:&#x2F;&#x2F;git.bejocama.org" rel="nofollow">http:&#x2F;&#x2F;git.bejocama.org</a><p>[4] <a href="http:&#x2F;&#x2F;ats-lang.sourceforge.net&#x2F;DOCUMENT&#x2F;INT2PROGINATS&#x2F;HTML&#x2F;c2016.html" rel="nofollow">http:&#x2F;&#x2F;ats-lang.sourceforge.net&#x2F;DOCUMENT&#x2F;INT2PROGINATS&#x2F;HTML&#x2F;...</a>
评论 #24337155 未加载
评论 #24336142 未加载
评论 #24335970 未加载
评论 #24336131 未加载
评论 #24336672 未加载
评论 #24336014 未加载
评论 #24335987 未加载
评论 #24336254 未加载
评论 #24336317 未加载
评论 #24336715 未加载
评论 #24336723 未加载
评论 #24336617 未加载
评论 #24337001 未加载
评论 #24336586 未加载
评论 #24336186 未加载
m00dy超过 4 年前
I believe someone will show up and rewrite entire kernel in Rust.
评论 #24340000 未加载
egberts1超过 4 年前
So glad that Rust at 1.38 ditched the Ada model of compiling all dependent modules firstly.
评论 #24337683 未加载
The_rationalist超过 4 年前
It&#x27;s not about safety, if that was the real argument we should start with obvious improvements like checked C <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;checkedc" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;checkedc</a> The C++ lifetime checker or Cyclone
评论 #24336480 未加载
msla超过 4 年前
What kind of performance hit is rewriting part of the kernel in Rust going to entail when it comes to compiling the kernel? How many platforms will cease to be able to compile their own kernels? The article says there will be some, but doesn&#x27;t give numbers.<p>More worryingly, the article also says that only some platforms will be &quot;Rusted&quot; in this manner, splitting the codebase into &quot;mainline Rust&quot; and &quot;obscure platform C&quot; as far as these sections are concerned; this seems like it will fracture the development community between people who know Rust and those who don&#x27;t, and those who can work on mainstream platforms and those who can&#x27;t. Fewer eyes on this code seems like the wrong way to go.
评论 #24337445 未加载
评论 #24337634 未加载
chromedev超过 4 年前
Pretty soon they&#x27;ll be arguing for inclusion of JavaScript in the Linux kernel