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

301–310 of 853 posts

Re: Rust in the kernel is no longer experimental

#301

Post by pjmlp »

johncolanduoni wrote: post #296
pjmlp wrote: post #279

Earlier quoted context omitted.

Unless rules have changed Rust is only allowed a minor role in Chrome. > Based on our research, we landed on two outcomes for Chromium. > We will support interop in only a single direction, from C++ to Rust, for now. Chromium is written in C++, and the majority of stack frames are in C++ code, right from main() until exit(), which is why we chose this direction. By limiting interop to a single direction, we control t…

> Unless rules have changed Rust is only allowed a minor role in Chrome. I believe the Chromium policy has changed, though I may be misinterpreting: https://chromium.googlesource.com/chromium/src/+/refs/heads/... The V8 developers seem more excited to use it going forward, and I’m interested to see how it turns out. A big open question about the Rust safety model for me is how useful it is for reducing the kind of bu…

That looks only to be the guidelines on how to integrate Rust projects, not that the policy has changed.

The NDK officially it isn't to write apps anyway, people try to do that due to some not wanting to touch Java or Kotlin, but that has never been the official point of view from Android team since it was introduced in version 2, rather:

> The Native Development Kit (NDK) is a set of tools that allows you to use C and C++ code with Android, and provides platform libraries you can use to manage native activities and access physical device components, such as sensors and touch input. The NDK may not be appropriate for most novice Android programmers who need to use only Java code and framework APIs to develop their apps. However, the NDK can be useful for cases in which you need to do one or more of the following:

> Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations.

> Reuse your own or other developers' C or C++ libraries.

So it would be expected that at least for the first scenario, Rust would be a welcomed addition, however as mentioned they seem to be more keen into supporting Kotlin Native for it.

Re: Rust in the kernel is no longer experimental

#302

Post by littlestymaar »

brabel wrote: post #146
littlestymaar wrote: post #89

Earlier quoted context omitted.

IMHO Zig doesn't bring enough value of its own to be worth bearing the cost of another language in the kernel. Rust is different because it both: - significantly improve the security of the kernel by removing the nastiest class of security vulnerabilities. - And reduce cognitive burden for contributors by allowing to encode in thr typesystem the invariants that must be upheld. That doesn't mean Zig is a bad language…

Zig as a language is not worth, but as a build system it's amazing. I wouldn't be surprised if Zig gets in just because of the much better build system than C ever had (you can cross compile not only across OS, but also across architecture and C stlib versions, including musl). And with that comes the testing system and seamless interop with C, which make it really easy to start writing some auxiliary code in Zig...…

I agree with you that it's much more interesting than the language, but I don't think it matters for a project like the Kernel that already had its build system sorted out. (Especially since no matter how nice and convenient Zig makes cross-compilation if you start a project from scratch, even in Rust thanks to cargo-zigbuild, it would require a lot of efforts to migrate the Linux build system to Zig, only to realize it doesn't support all the needs of the kernel at the start).

Re: Rust in the kernel is no longer experimental

#303

Post by johncolanduoni »

mustache_kimono wrote: post #111
johncolanduoni wrote: post #103

Earlier quoted context omitted.

You almost certainly have a bunch of devices containing a microcontroller that runs an architecture not targeted by LLVM. The embedded space is still incredibly fragmented. That said, only a handful of those architectures are actually so weird that they would be hard to write a LLVM backend for. I understand why the project hasn’t established a stable backend plugin API, but it would help support these ancillary arch…

> You almost certainly have a bunch of devices containing a microcontroller that runs an architecture not targeted by LLVM. This is exactly what I'm saying. Do you think HW drives SW or the other way around? When Rust is in the Linux kernel, my guess is it will be very hard to find new HW worth using, which doesn't have some Rust support.

In embedded, HW drives SW much more than the other way around. Most microcontrollers are not capable of running a Linux kernel as it is, even with NoMMU. The ones that are capable of this are overwhelmingly ARM or RISC-V these days. There’s not a long list of architectures supported by the modern Linux kernel but not LLVM/Rust.

Re: Rust in the kernel is no longer experimental

#306

Post by eru »

ahartmetz wrote: post #241
arbitrandomuser wrote: post #167

Earlier quoted context omitted.

what is an intrusive data structure?

A container class that needs cooperation from the contained items, usually with special data fields. For example, a doubly linked list where the forward and back pointers are regular member variables of the contained items. Intrusive containers can avoid memory allocations (which can be a correctness issue in a kernel) and go well with C's lack of built-in container classes. They are somewhat common in C and very rar…

At least for a double linked list you can probably get pretty far in terms of performance in the non-intrusive case, if your compiler unboxes the contained item into your nodes? Or are there benefits left in intrusive data structures that this doesn't capture?

Re: Rust in the kernel is no longer experimental

#307

Post by eru »

ViewTrick1002 wrote: post #221
biorach wrote: post #196

Earlier quoted context omitted.

Yeah, if you need a linked list (you probably don't) use that. If however you are one of the very small number of people who need fine-grained control over a tailored data-structure with internal cross-references or whatnot then you may find yourself in a world where Rust really does not believe that you know what you are doing and fights you every step of the way. If you actually do know what you are doing, then Zig…

The point with the linked list is that it is perfectly valid to use unsafe to design said ”tailored data structure with internal cross-reference or what not” library and then expose a safe interface. If you’re having trouble designing a safe interface for your collection then that should be a signal that maybe what you are doing will result in UB when looked at the wrong way. That is how all standard library collecti…

> If you’re having trouble designing a safe interface for your collection then that should be a signal that maybe what you are doing will result in UB when looked at the wrong way.

Rust is great, but there are some things that are safe (and you could prove them safe in the abstract), but that you can't easily express in Rust's type system.

More specifically, there are some some things and usage pattern of these things that are safe when taken together. But the library can't force the safe usage pattern on the client, with the tools that Rust provides.

Re: Rust in the kernel is no longer experimental

#308

Post by eru »

jcranmer wrote: post #32
drnick1 wrote: 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.

There is a set of languages which are essentially required to be available on any viable system. At present, these are probably C, C++, Perl, Python, Java, and Bash (with a degree of asterisks on the last two). Rust I don't think has made it through that door yet, but on current trends, it's at the threshold and will almost certainly step through. Leaving this set of mandatory languages is difficult (I think Fortran,…

> Rust I don't think has made it through that door yet, but on current trends, it's at the threshold and will almost certainly step through.

I suspect what we are going to see isn't so much Rust making it through that door, but LLVM. Rust and friends will come along for the ride.

Re: Rust in the kernel is no longer experimental

#309

Post by saagarjha »

sroussey wrote: post #238
jcranmer wrote: post #36

Earlier quoted context omitted.

CHERI has 64-bit object size but 128-bit pointers (because the pointer values also carry pointer provenance metadata in addition to an address). I know some of the pointer types on GPUs (e.g., texture pointers) also have wildly different sizes for the address size versus the pointer size. Far pointers on segmented i386 would be 16-bit object and index size but 32-bit address and pointer size. There was one accelerato…

I guess today, instead of 128bit pointers we have 64bit pointers and secret provenance data inside the cpu, at least on the most recent shipped iPhones and Macs. In the end, I’m not sure that’s better, or maybe we should have had extra large pointers again (in that way back 32bit was so large we stuffed other stuff in there) like CHERI proposes (though I think it still has secret sidecar of data about the pointers).…

It's not secret, it just reuses some of the unused address bits.

Re: Rust in the kernel is no longer experimental

#310

Post by eru »

ottah wrote: post #59
brokencode wrote: post #19

Earlier quoted context omitted.

What other newfangled alternative to C was ever adopted in the Linux kernel? I have no doubt C will be around for a long time, but I think Rust also has a lot of staying power and won’t soon be replaced.

I wouldn't be surprised to see zig in the kernel at some point

I would be. Mostly because while Zig is better than C, it doesn't really provide all that much benefit, if you already have Rust.
Post reply on HN