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

Rust in the kernel is no longer experimental

lwn.net

Post reply on HN
Print view View original

531–540 of 853 posts

Re: Rust in the kernel is no longer experimental

#531

Post by kaoD »

menaerus wrote: post #434
baq wrote: post #401

Earlier quoted context omitted.

> I don't know what one should even make from that statement. it's just a fact. by definition of the Rust language unsafe Rust is approximately as safe as C (technically Rust is still safer than C in its unsafe blocks, but we can ignore that.) > you didn't even bother to look at the code but still presented of course I did, what I've seen were one-liner trait impls (the 'whole traits' from your own post) and sub-line…

So, unsafe block every 70 LoC in 1500 LoC toy example? Sure, it's a strong argument.

How is that worse than everything being unsafe?

I've seen this argument thrown around often here in HN ("$IMPROVEMENT is still not perfect! So let's keep the statu quo.") and it baffles me.

C is not perfect and it still replaced ASM in 99% of its use cases.

Re: Rust in the kernel is no longer experimental

#532

Post by Eikon »

I'm mostly interested in being able to interact with the vfs and build a 9p rust client (in addition to the current v9fs) to support my 9p server [0].

Does anyone know what's the current state / what is the current timeline for something like this to be feasible?

[0] https://github.com/Barre/ZeroFS

Re: Rust in the kernel is no longer experimental

#533

Post by ijustlovemath »

bmicraft wrote: post #487
muvlon wrote: post #425

Earlier quoted context omitted.

In order to figure this out I took the list of platforms supported by Rust from https://doc.rust-lang.org/nightly/rustc/platform-support.htm... and those supported by Linux from https://docs.kernel.org/arch/index.html , cleaned them up so they can be compared like for like and then put them into this python script: linux = { "alpha", "arc", "arm", "aarch64", "csky", "hexagon", "loongarch", "m68k", "microblaze", "mips…

Well, GCC 15 already ended support for the nios2 soft-core. The successor to it is Nios V which runs RISC-V. If users want us update the kernel, they'll also need to update their FPGA. Microblaze also is a soft-core, based on RISC-V, presumably it could support actual RISC-V if anyone cared. All others haven't received new hardware within the last 10 years, everybody using these will already be running an LTS kernel…

Is this the same NIOS that runs on FPGA? We wrote some code for it during digital design in university, and even an a.out was terribly slow, can't imagine running a full kernel. Though that could have been the fault of the hardware or IP we were using.

Re: Rust in the kernel is no longer experimental

#534

Post by cogman10 »

FpUser wrote: post #506
cogman10 wrote: post #349

Earlier quoted context omitted.

Depends on the change being made. If they completely replace an API then sure, probably. But for most changes, like adding a param to a function or a struct, they basically have to learn nothing. Rust isn't unlike C either. You can write a lot of it in a pretty C like fashion.

>"Rust isn't unlike C either. You can write a lot of it in a pretty C like fashion." I think that with all of the Rust's borrowing rules the statement is very iffy.

Rust's borrowing rules might force you to make different architecture choices than you would with C. But that's not what I was thinking about.

For a given rust function, where you might expect a C programmer to need to interact due to a change in the the C code, most of the lifetime rules will have already been hammered out before the needed updates to the rust code. It's possible, but unlikely, that the C programmer is going to need to significantly change what is being allocated and how.

Re: Rust in the kernel is no longer experimental

#535

Post by bmacho »

pjmlp wrote: post #359
bmacho wrote: post #325

Earlier quoted context omitted.

According to the internet (can't check now) Alpine doesn't come with perl installed.

So a distribution mostly used to deploy containers.

"Alpine Linux is a general purpose Linux distribution" https://wiki.alpinelinux.org/wiki/Tutorials_and_Howtos

I don't agree with "any modern system" but some modern systems certainly don't come with perl.

Re: Rust in the kernel is no longer experimental

#536

Post by timeon »

encom wrote: post #478
weebull wrote: post #455

Earlier quoted context omitted.

I don't understand why. Working with hardware you're going to have to do various things with `unsafe`. Interfacing to C (the rest of the kernel) you'll have to be using `unsafe`. In my mind, the reasoning for rust in this situation seems flawed.

[flagged]

What was the question? I saw only one assumption.

Re: Rust in the kernel is no longer experimental

#537

Post by duped »

bayindirh wrote: post #411
iurbwdj wrote: post #395

Earlier quoted context omitted.

https://lkml.org/lkml/2025/2/6/1292

Some pretext: I'm a Rust skeptic and tired of Rust Evangelism Task Force and Rewrite in Rust movements. --- Yes. I remember that message. Also let's not forget what marcan said [0] [1]. In short, a developer didn't want their C codebase littered with Rust code, which I can understand, then the Rust team said that they can maintain that part, not complicating his life further (Kudos to them), and the developer lashing…

> In short, a developer didn't want their C codebase littered with Rust code

from reading those threads at the time, the developer in question was deliberately misunderstanding things. "their" codebase wasn't to be "littered" with Rust code - it wasn't touched at all.

Re: Rust in the kernel is no longer experimental

#538

Post by hollerith »

jacquesm wrote: post #521
hollerith wrote: post #511

Earlier quoted context omitted.

Aren't large parts of a web browser and a runtime for a programming language also better written in Rust than in Go or Java?

I'd say no, access to a larger pool of programmers is an important ingredient in the decision of what you want to write something in. Netscape pre-dated Java which is why it was written in C/C++ and that is why we have rust in the first place. But today we do have Java which has all of the rust safety guarantees and then some, is insanely performant for network code and has a massive amount of mindshare and available…

All the mainstream browsers do their own low-level graphics rendering (e.g., of text and icons and such). Is Java performant enough to do that?

Re: Rust in the kernel is no longer experimental

#539

Post by timeon »

bigfishrunning wrote: post #492
semiinfinitely wrote: post #93

This is great because it means someday (possibly soon) Linux development will slowly grind to a halt and become unmaintainable, so we can start from scratch and write a new kernel.

You can start from scratch and write a new kernel now! Nothing's stopping you.

Ideally in Rust.

Re: Rust in the kernel is no longer experimental

#540

Post by SAI_Peregrinus »

maweki wrote: post #149
ZeWaka wrote: post #142

Earlier quoted context omitted.

Yeah, not sure what they're saying... I use bitfields in multiple of my rust projects using those macros.

I'm not a rust or systems programmer but I think it meant that as an ABI or foreign function interface bitfields are not stable or not intuitive to use, as they can't be declared granularily enough.

C's bit-fields ABI isn't great either. In particular, the order of allocation of bit-fields within a unit and alignment of non-bit-field structure members are implementation defined (6.7.2.1). And bit-fields of types other than `_Bool`, `signed int` and `unsigned int` are extensions to the standard, so that somewhat limits what types can have bitfields.
Post reply on HN