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

31–40 of 365 posts

Re: Supporting Linux kernel development in Rust

#31

Post by homarp »

guerrilla wrote: post #10
_8j50 wrote: post #7

Earlier quoted context omitted.

Maybe a GNU Rust compiler without the trademark is in order? The state of KSPP is not nice as well. I wish Ada was more popular. From what I know, it has much of the security guarantees rust has and it has been battle tested.

I'm not sure, but aren't they saying that they wouldn't be able to call it "GNU Rust" [1] in the same way they can't call IceCat "GNU Firefox"? 1. https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...

well, plenty of names to play with:)

GNR: Gnr Not Rust

TRust: Treated Rust

...

Re: Supporting Linux kernel development in Rust

#32

Post by JoshTriplett »

danudey wrote: post #25
dijit wrote: post #11

Earlier quoted context omitted.

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 Cl…

Originally, we thought that Linux maintainers were asking us to only support kernels compiled with Clang, because they didn't want to support code built with two different compilers. However, in the session, Greg Kroah-Hartman specifically said that if it works to build Rust code with the LLVM-based rustc and C code with GCC and link the two together, and there aren't any problems in practice, then that's perfectly fine.

So, we're currently expecting that supporting Rust will not place any requirements on the C compiler you use, unless you want to use cross-language LTO (which we'll eventually want to do, but it won't be a hard requirement for a working kernel).

Re: Supporting Linux kernel development in Rust

#33

Post by ATsch »

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'm not sure why you'd need a VM for this. It should be much easier to implement bridges for major kernel apis like character devices, as I understand some BSDs already do?

Re: Supporting Linux kernel development in Rust

#34

Post by JoshTriplett »

bitwize wrote: post #28
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 st…

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

#35

Post by ColanR »

JoshTriplett wrote: post #15
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…

The vast majority of the text in that post is inaccurate and hyperbolic. Linux is not "forcing adoption of HDCP" (it's just something Linux has a driver for), Rust does not require internet access to use (and the trademark comments are not particularly accurate either), the Kernel Self Protection Project is alive and well and making new improvements in every new version of the kernel (see Kees Cook's regular blog pos…

I think you were being "inaccurate and hyperbolic".

> Linux is not "forcing adoption of HDCP" (it's just something Linux has a driver for)

What they actually said in the article:

> Historically, some features began as optional ones until they reached total functionality. Then they became forced and difficult to patch out. Even if this does not happen in the case of HDCP, we remain cautious about such implementations.

Re: Supporting Linux kernel development in Rust

#36

Post by _8j50 »

guerrilla wrote: post #10
_8j50 wrote: post #7

Earlier quoted context omitted.

Maybe a GNU Rust compiler without the trademark is in order? The state of KSPP is not nice as well. I wish Ada was more popular. From what I know, it has much of the security guarantees rust has and it has been battle tested.

I'm not sure, but aren't they saying that they wouldn't be able to call it "GNU Rust" [1] in the same way they can't call IceCat "GNU Firefox"? 1. https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...

They can call it something else entirely. Rusty? Brown? Who cares so long as it is compatible with rustc

Re: Supporting Linux kernel development in Rust

#37

Post by [deleted] »

JoshTriplett wrote: post #15
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…

The vast majority of the text in that post is inaccurate and hyperbolic. Linux is not "forcing adoption of HDCP" (it's just something Linux has a driver for), Rust does not require internet access to use (and the trademark comments are not particularly accurate either), the Kernel Self Protection Project is alive and well and making new improvements in every new version of the kernel (see Kees Cook's regular blog pos…

[deleted]

Re: Supporting Linux kernel development in Rust

#38

Post by jcranmer »

JoshTriplett wrote: post #32
danudey wrote: post #25

Earlier quoted context omitted.

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 Cl…

Originally, we thought that Linux maintainers were asking us to only support kernels compiled with Clang, because they didn't want to support code built with two different compilers. However, in the session, Greg Kroah-Hartman specifically said that if it works to build Rust code with the LLVM-based rustc and C code with GCC and link the two together, and there aren't any problems in practice, then that's perfectly f…

> unless you want to use cross-language LTO (which we'll eventually want to do, but it won't be a hard requirement for a working kernel).

Does Linux even work with LTO right now? It seems to do a lot of weird-linking-magic things that I wouldn't expect to work well with LTO.

Re: Supporting Linux kernel development in Rust

#39

Post by gpm »

homarp wrote: post #31
guerrilla wrote: post #10

Earlier quoted context omitted.

I'm not sure, but aren't they saying that they wouldn't be able to call it "GNU Rust" [1] in the same way they can't call IceCat "GNU Firefox"? 1. https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...

well, plenty of names to play with:) GNR: Gnr Not Rust TRust: Treated Rust ...

How do you pronounce GNR? It think it needs to be a vowel, or an R.

Some attempts: GRR: Gnu Renames Rust, GAR: Gnu assimilates rust, GER: Gnu non Est Rust (gnu is not rust, but in latin to get an E), GIR: Gnu Isn't Rust, GOR: Gnu Oxidizes Rust, GUR: Gnu Unseats Rust.

Re: Supporting Linux kernel development in Rust

#40

Post by JoshTriplett »

ColanR wrote: post #35
JoshTriplett wrote: post #15

Earlier quoted context omitted.

The vast majority of the text in that post is inaccurate and hyperbolic. Linux is not "forcing adoption of HDCP" (it's just something Linux has a driver for), Rust does not require internet access to use (and the trademark comments are not particularly accurate either), the Kernel Self Protection Project is alive and well and making new improvements in every new version of the kernel (see Kees Cook's regular blog pos…

I think you were being "inaccurate and hyperbolic". > Linux is not "forcing adoption of HDCP" (it's just something Linux has a driver for) What they actually said in the article: > Historically, some features began as optional ones until they reached total functionality. Then they became forced and difficult to patch out. Even if this does not happen in the case of HDCP, we remain cautious about such implementations.

My comment was entirely based on the second link. Direct quote from that:

> Linux kernel forcing adaption of DRM, including HDCP.

(Which linked to a patch adding driver support for handling HDCP, with absolutely no possibility of it somehow being forced.)

Regarding the quote from that interview: sure, and there's also no guarantee that the Linux kernel won't drop support for every architecture except SPARC, except of course for all the people involved not putting up with it. In what possible universe would Linux developers decide it was a good idea to mandate HDCP? It's completely unfounded and unsupported hyperbole and fearmongering, without even a hint of potential truth.

It's also roughly consistent with what I'd expect from someone who thinks that gettext daring to have support for Java and C# format strings is a horrific problem that should be ripped out by the roots.

Post reply on HN