Live data from Hacker News

Rust in the kernel is no longer experimental

lwn.net

591–600 of 853 posts

Re: Rust in the kernel is no longer experimental

#591
post #532

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

If you just want to play https://github.com/cberner/fuser

Re: Rust in the kernel is no longer experimental

#592
post #340

Earlier quoted context omitted.

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

linus torvalds

Linus Torvalds greenlit Rust in the kernel, and as a BDFL, he is the one to decide. He has no reason to be upset with any decision because ultimately, all decisions are his own.

If he didn't want Rust in the kernel, he would have said it, and there would have been no Rust in the kernel. It is also the reason why there is no C++ in the kernel, Linus doesn't like C++. It is that simple.

And I respect that, Linux is hugely successful under Linus direction, so I trust his decisions, whatever opinion I have about them.

Re: Rust in the kernel is no longer experimental

#593

Earlier quoted context omitted.

I don't think unsafe Rust has gotten any easier to write, but I'd also be surprised if there was much unsafe except in the low-level stuff (hard to write Vec without unsafe), and to interface with C which is actually not hard to write. Mostly Rust has been used for drivers so far. Here's the first Rust driver I found: https://github.com/torvalds/linux/blob/2137cb863b80187103151... It has one trivial use of `unsafe` -…

Drivers are interesting from a safety perspective, because on systems without an IOMMU sending the wrong command to devices can potentially overwrite most of RAM. For example, if the safe wrappers let you write arbitrary data to a PCIe network card’s registers you could retarget a receive queue to the middle of a kernel memory page.

In normal user-mode rust, not running inside the kernel at all, you can open /dev/mem and write whatever you want to any process's memory (assuming you are root). This does not require "unsafe" at all.

Another thing you can do from rust without "unsafe": output some buggy source code that invokes UB in a language like C to a file, then shell out to the compiler to compile that file and run it.

Re: Rust in the kernel is no longer experimental

#594

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.

Unsafe in Rust doesn't mean anything goes. Specifically it means that you are going to 1) dereference a raw pointer; or 2) call an unsafe function/method; or 3) access/modify a mutable static variable; or 4) implement an unsafe trait; or 5) access fields of a union.

You still get the safety guarantees of Rust in unsafe code like bounds checking and lifetimes.

Re: Rust in the kernel is no longer experimental

#595

Earlier quoted context omitted.

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?

Absolutely. Again, not a fan of the language. But you can transcode 10's of video streams on a single machine into a whole pile of different output resolutions and saturate two NICs while you're at it. Java has been 'fast enough' for almost all purposes for the last 10 years at least if not longer. The weak point will always be the startup time of the JVM which is why you won't see it be used for short lived processe…

It’s only fast enough if it is as fast or faster than the alternatives. Otherwise it is wasting battery power, making older/cheaper computers feel sluggish and increasingly inefficient.

Re: Rust in the kernel is no longer experimental

#596
post #14

Earlier quoted context omitted.

Every system under the Sun has a C compiler. This isn't remotely true for Rust. Rust is more modern than C, but has it's own issues, among others very slow compilation times. My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.

One problem of Rust vs C, I rarely see mentioned is that Rust code is hard to work with from other languages. If someone writes a popular C library, you can relatively easily use it in your Java, D, Nim, Rust, Go, Python, Julia, C#, Ruby, ... program. If someone writes a popular Rust library, it's only going to be useful to Rust projects. With Rust I don’t even know if it’s possible to make borrow checking work acros…

The reason you rarely hear that mentioned is because basically every programming language is hard to work with from other languages. The usual solution is to "just" expose a C API/ABI.

Of course, C API/ABIs aren't able to make full use of Rust features, but again, that also applies to basically every other language.

Re: Rust in the kernel is no longer experimental

#597

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…

> What is then extra strange is that there have been some public hostility against gccrs (WIP Rust compiler for gcc) from the rustc (sole main Rust compiler primarily based on LLVM) camp. Could you point at a single quote from a member of the compiler team, current or former, that can be construed as hostility?

For what it’s worth, I perceived hostility here a long time ago, but those people have pretty explicitly come around since. That said I also think the parent is just wrong to focus on gcc vs llvm as the source of that, and also to bring it up at this point regardless.

Re: Rust in the kernel is no longer experimental

#598
post #472

Earlier quoted context omitted.

Does this image count as significant tribalism in parts of the Rust community? https://github.com/microsoft/typescript-go/discussions/411#d... Taken from the above Github discussion regarding Go and Typescript. https://imgur.com/a/efdIuWb

How is the one comment from a GH account with 18 followers, no contribution to the Rust project (or any Rust based project at all) and mostly contributions to javascript projects in any way representative of the Rust community? Especially taken out of context - in context it seem like a failed(?) attempt at humor or sarcasm. Do I treat your post from an obvious throwaway account created 13 minutes ago as somehow repr…

> Do I treat your post from an obvious throwaway account created 13 minutes ago as somehow representative of the C community or the Linux kernel community or for that matter as representative of any community at all?

For all we know it could be the same person behind both the GitHub post and the Hacker News throwaway you're speaking to.

Re: Rust in the kernel is no longer experimental

#599

Earlier quoted context omitted.

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.

Data races are possible on some types, specifically `long` when not declared as `volatile` - but these do not directly cause memory unsafety.

Re: Rust in the kernel is no longer experimental

#600

Earlier quoted context omitted.

> supports 14 of the kernel's 20-ish architectures That's a lot better than I expected to be honest, I was thinking maybe Rust supported 6-7 architectures in total, but seems Rust already has pretty wide support. If you start considering all tiers, the scope of support seems enormous: https://doc.rust-lang.org/nightly/rustc/platform-support.htm...

They probably get a few for "free" from LLVM supporting them

Wasn't that a whole tent pole of LLVM?
Post reply on HN