Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supporting Linux kernel development in Rust

lwn.net

Post reply on HN
Print view View original

21–30 of 365 posts

Re: Supporting Linux kernel development in Rust

#21

Post by Macha »

cylon13 wrote: post #18
Macha wrote: post #16

Earlier quoted context omitted.

The licensing complaints about Rust apply equally to Python, which they package without objection: https://www.hyperbola.info/packages/extra/x86_64/python/

Not exactly: [0] > Some users have correctly mentioned that many other software packages have trademarks, do we plan to remove them all? No. We are not against all trademarks, only those which explicitly prohibit normal use, patching, and modification. > As an example, neither Python PSF nor Perl Trademarks currently prohibit patching the code without prior approval. They do prohibit abuse of their trademarks, e.g. y…

Well, good luck calling your modified Python release Python: https://github.com/naftaliharris/tauthon/issues/47

Re: Supporting Linux kernel development in Rust

#22

Post by gpm »

Thaxll wrote: post #3

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.

There is no doubt a lot of work here, but C Rust interoperability is a lot cleaner than C++ Rust.

And for what it's worth, for almost all langauges C X interoperability is a lot cleaner than C++ X. Since almost all languages (including rust) "speak C", both in terms of compiler support and and being able to map every important C concept to a concept in their language. The same isn't true with C++.

One thing to worry about with adding any language (including rust) to the kernel, is that the next good looking language will probably interoperate well with C and not interoperate well with Rust. So there is a much higher cost the second time you try to add a language.

Re: Supporting Linux kernel development in Rust

#23

Post by muricula »

stmw wrote: post #13
Thaxll wrote: post #3

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.

Can you elaborate re: issues and lots of work required? I think it's generally to be expected that non-C language support in the kernel would be hard...

Here's the article the parent mentioned in passing, it may answer your question: https://www.chromium.org/Home/chromium-security/memory-safet...

It's very Chrome and C++ specific, but the problems will likely be similar in practice.

Re: Supporting Linux kernel development in Rust

#24

Post by JoshTriplett »

dijit wrote: post #11
jcranmer wrote: post #5

Earlier quoted context omitted.

If I'm understanding correctly, the only reason for not using Rust is... Rust is trademarked?

I'm generally in support of rust in the kernel, but in the interest of playing devils advocate: Would adding more and more dependence on rust mean that it ties the kernel to a single set of compilers? I can see why people would be opposed to that. I'm thinking about LLVM (and, obviously, rustc)

Linux currently only compiles on GCC and Clang, and the latter is a recent development. rustc uses LLVM as a backend, just like Clang, and people are working on other backends. Linux maintainers didn't express any concerns about this being an issue.

Re: Supporting Linux kernel development in Rust

#25

Post by danudey »

dijit wrote: post #11
jcranmer wrote: post #5

Earlier quoted context omitted.

If I'm understanding correctly, the only reason for not using Rust is... Rust is trademarked?

I'm generally in support of rust in the kernel, but in the interest of playing devils advocate: Would adding more and more dependence on rust mean that it ties the kernel to a single set of compilers? I can see why people would be opposed to that. I'm thinking about LLVM (and, obviously, rustc)

The Linux kernel would only compile with GCC for... decades? I think? So it's not really a new thing. It would be really nice if the kernel did have first-class support for LLVM and Clang directly (rather than having to set a bunch of environment variables to set the compiler, the linker to use with that compiler, various variables, etc.

That said, it would certainly be uncomfortable to move from "it compiles with Clang, though it's a pain, or GCC, which works fine" to "it compiles with GCC, if you don't use any of this functionality, or LLVM only, if you want any of these features or anything that depends on them".

Re: Supporting Linux kernel development in Rust

#26

Post by ender341341 »

Thaxll wrote: post #3

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.

Most of the chrome teams issues stemmed from C++'s lack of an ABI, not wanting to deal with using unsafe around the C++ interfaces & not wanting to have to annotate c++ to export it to rust.

I'd say the biggest questions for Linux that may be blocking here relate to LLVM not being available on nearly as many platforms as GCC (many of which will likely never be supported cause they're legacy systems that are only supported in the sense that they aren't purposefully broken) which limits it's use in any core-ish kernel systems.

Re: Supporting Linux kernel development in Rust

#27

Post by ColanR »

puzzledobserver wrote: post #9

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. 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 b…

I was thinking about something similar recently - if the hardware drivers could somehow be abstracted from the rest of the linux kernel (as if...), then suddenly a ton of experimental kernels could have widespread hardware availability.

It would probably shake up the OS ecosystem to no small degree, but I imagine the fresh ideas that could be experimented with by non-experts would be hugely beneficial. Isn't that the big argument against so many new projects? "It looks cool, but the hardware support isn't there."

FreeBSD might be a better target though, since that's specifically designed to be compatible with everything.

Re: Supporting Linux kernel development in Rust

#28

Post by bitwize »

boogies wrote: post #2

Probably a crazy unpopular opinion, but I kind of agree with the Hyperbola (GNU / formerly Linux-libre, in future using a fork of the OpenBSD kernel https://itsfoss.com/hyperbola-linux-bsd/ ) devs that Rust in Linux is not necessarily a good thing, for the reasons they mentioned when they announced they were switching kernels ( https://www.hyperbola.info/news/announcing-hyperbolabsd-road... ) (Edit: and the LLVM depe…

I'd be more concerned about the fact that the Rust Evangelism Strike Force is hellbent on getting everybody to depend on their exhausts-all-32-bit-address-space-to-build compiler and toolchain -- in addition to whatever toolchain the project currently uses, at least as long as the strangler pattern is being applied to migrate the code base to 100% Rust. GNU software in particular has always been such that the core stuff is bootstrappable from just C.

But it seems, from an RESF standpoint, that the fact that any C code is out there running at all is a crisis-level problem.

Re: Supporting Linux kernel development in Rust

#29

Post by JoshTriplett »

puzzledobserver wrote: post #9

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. 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 b…

The point of this LPC session was how to incrementally introduce Rust in the existing Linux kernel, with all its existing drivers and syscalls and similar. A rewrite would indeed be a daunting and problematic proposition.

There are kernels written in Rust, such as Redox, but those are separate projects, and that's not what this conference session or article are talking about.

Standing reminder: the Rust project is not a fan of rabid Rust over-evangelism (e.g. "Rewrite It In Rust", "Rust Evangelism Strike Force"), and sees it as damaging and unhelpful. We discourage that kind of thing wherever we see it. We're much more in favor of a measured, cautious approach.

Re: Supporting Linux kernel development in Rust

#30

Post by ghostwriter »

I won't get tired of repeating the same comment in every topic that suggests Rust to be a great replacement of C in existing projects, that it isn't.

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 ("one can define a kmalloc_for_rust() symbol containing an un-inlined version"), 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.

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].

[1] http://www.ats-lang.org/Documents.html#INT2PROGINATS

[2] https://www.reddit.com/r/ATS/comments/ibyczp/ats_linux/

[3] http://git.bejocama.org

[4] http://ats-lang.sourceforge.net/DOCUMENT/INT2PROGINATS/HTML/...

Post reply on HN