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

581–590 of 853 posts

Re: Rust in the kernel is no longer experimental

#581

Post by School-Cotton »

bayindirh wrote: post #476
iurbwdj wrote: post #441

Earlier quoted context omitted.

One perspective is that Rust appears to be forced into the Linux kernel through harassment and pressure. Instead of Rust being pulled, carefully, organically and friendly, and while taking good care of any significant objections. Objections like, getting the relevant features from unstable Rust into stable Rust, or getting a second compiler like gccrs (Linux kernel uses gcc for C) fully up and running, or ensuring th…

Personally, I observe that Rust is forced everywhere in the Linux ecosystem. One of my biggest concerns is uutils, mostly because of the permissive license it bears. The Linux kernel and immediate userspace shall be GPL licensed to protect the OS in my opinion. I have a personal principle of not using LLVM-based languages (equal parts I don't like how LLVM people behave against GCC and I support free software first a…

LLVM is free software. You appear to be making the common mistake of confusing the permissive vs. copyleft distinction with the open source vs. free software distinction.

Open source and free software mean almost exactly the same set of software; the only difference between the two terms, according to RMS and other free software advocates, is the emphasis. Sort of like the difference between the Gulf of America and the Gulf of Mexico: they mean the same body of water, but reflect a different viewpoint about it.

This confusion arises because RMS prefers the term "free software" over "open source", and also prefers copyleft over permissive licenses, so people sort of get the idea that they are the same distinction.

Re: Rust in the kernel is no longer experimental

#582

Post by zozbot234 »

kbolino wrote: post #547
aw1621107 wrote: post #55

Earlier quoted context omitted.

> Is it something that can be fixed with editions? My guess is no, or at least not easily. Assuming I'm reading these blog posts [0, 1] correctly, it seems that the size_of:: () == size_of:: () assumption is changeable across editions. Or at the very least, if that change (or a similarly workable one) isn't possible, both blog posts do a pretty good job of pointedly not saying so. [0]: https://faultlore.com/blah/fix-…

Great info! Personally, I like 3.1.2 from your link [0] best, which involves getting rid of pointer integer casts entirely, and just adding methods to pointers, like addr and with_addr. This needs no new types and no new syntax, though it does make pointer arithmetic a little more cumbersome. However, it also makes it much clearer that pointers have provenance. I think the answer to "can this be solved with editions"…

AIUI, this particular change would only impact some newly supported architectures going forward. These don't need to be buildable with older editions.

Re: Rust in the kernel is no longer experimental

#583

Post by mewse-hn »

bpavuk wrote: post #340
teekert wrote: post #176

Earlier quoted context omitted.

Yeah I was wondering about that one angry bearded guy in that movie. He will be very upset.

I am missing some context, did not follow the Linux/Rust drama. which guy?

Ted T'so: "Here’s the thing: you’re not going to force all of us to learn Rust."

https://arstechnica.com/gadgets/2024/09/rust-in-linux-lead-r...

https://youtu.be/WiPp9YEBV0Q?t=1529

Re: Rust in the kernel is no longer experimental

#584

Post by structural »

vlovich123 wrote: post #130
jcranmer wrote: post #20

Earlier quoted context omitted.

C currently remains the language of system ABIs, and there remains functionality that C can express that Rust cannot (principally bitfields). Furthermore, in terms of extensions to the language to support more obtuse architecture, Rust has made a couple of decisions that make it hard for some of those architectures to be supported well. For example, Rust has decided that the array index type, the object size type, an…

Can you expand on bitfields? There’s crates that implement bitfield structs via macros so while not being baked into the language I’m not sure what in practice Rust isn’t able to do on that front.

Now, try and use two or more libraries that expose data structures with bitfields, and they have all chosen different crates for this (or even the same crate but different, non-ABI-compatible-versions of it).

There's a ton of standardization work that really should be done before these are safe for library APIs. Mostly fine to just write an application that uses one of these crates though.

Re: Rust in the kernel is no longer experimental

#585

Post by School-Cotton »

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…

> which has all of the rust safety guarantees and then some

That's not really true. Data races are possible in Java.

Re: Rust in the kernel is no longer experimental

#586

Post by steveklabnik »

tremon wrote: post #580
weinzierl wrote: post #271

That is so good to hear. I feel Rust support came a long way in the past two years and you can do a functional Rust kernel module now with almost no boilerplate. Removing the "experimental" tag is certainly a milestone to celebrate. I'm looking forward to distros shipping a default kernel with Rust support enabled. That, to me, will be the real point of no return, where Rust is so prevalent that there will be no goin…

> I'm looking forward to distros shipping a default kernel with Rust support enabled What does this mean? The kernel has no specific support for Rust userspace -- the syscall API does not suddenly change because some parts of the kernel are compiled with rustc.

They aren’t talking about userspace.

As I understand it, the kernel has a flag, no by default, to enable building rust code as part of the kernel. They’re saying they’d like to see a distributed choosing to default this flag to yes for the kernels they build.

Re: Rust in the kernel is no longer experimental

#587

Post by School-Cotton »

weebull wrote: post #455
ramon156 wrote: post #353

Earlier quoted context omitted.

Rightfully so, its probably the place where you'll het most ROI

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.

Why does that matter? Rust with some "unsafe" is still much nicer to use than C.

In fact one of the main points of Rust is the ability to build safe abstractions on top of unsafe code, rather than every line in the entire program always being unsafe and possibly invoking UB.

Re: Rust in the kernel is no longer experimental

#588

Post by ls-a »

jjice wrote: post #569
ls-a wrote: post #561

I never used linux because it was built using C++. Never have I cared what language the product was built it. The Rust community however wants you to use a product just because it's implemented in Rust, or atleast as one of the selling points. For that reason I decided to avoid any product that advertises using Rust as a selling point, as much as I can. Was planning to switch from Mac to a Linux machine, not anymore,…

It's an optional tool that can be used to implement drivers now, not forced. If you don't like the idea of another language being supported for implementing a subset of kernel modules, I don't think you wouldn't enjoyed having a Linux machine anyways.

That's not the case. It's using Rust as a selling point. All the noise around using Rust is marketing. The fact that you think linux machines are enjoyed by only a specific group of people makes me happier with my choice

Re: Rust in the kernel is no longer experimental

#589

Post by chippiewill »

dcrazy wrote: post #64

Does the removal of “experimental” now mean that all maintainers are now obligated to not break Rust code?

I believe the removal of the "experimental" nomenclature is just an indication that Rust is "here to stay" in the kernel (which essentially means that developers can have confidence investing in writing Rust based drivers).

The overall rules haven't changed.

Strictly speaking they've always been obligated to not break the Rust code, but the R4L developers have agreed to fix it on some subsystems behalf IIRC so Rust can be broken in the individual subsystem trees. But I think it's been the case all along that you can't send it to Linus if it breaks the Rust build, and you probably shouldn't send it to linux-next either.

Re: Rust in the kernel is no longer experimental

#590

Post by ls-a »

michaelmcmillan wrote: post #572
ls-a wrote: post #561

I never used linux because it was built using C++. Never have I cared what language the product was built it. The Rust community however wants you to use a product just because it's implemented in Rust, or atleast as one of the selling points. For that reason I decided to avoid any product that advertises using Rust as a selling point, as much as I can. Was planning to switch from Mac to a Linux machine, not anymore,…

Linux is written in C, my friend.

C, C++, I don't think you got the gist of what I said
Post reply on HN