Content-Length: 18493 | pFad | http://lwn.net/Articles/830293/

MIR is a wiser choice [LWN.net]
|
|
Subscribe / Log in / New account

MIR is a wiser choice

MIR is a wiser choice

Posted Sep 1, 2020 17:24 UTC (Tue) by Baughn (subscriber, #124425)
In reply to: MIR is a wiser choice by mkubecek
Parent article: Supporting Linux kernel development in Rust

Firefox development drives (drove?) Rust development, so of course it requires the latest nightly build.

There's no requirement for doing the same with Linux. Programs written against stable Rust ~never need changes due to new Rust releases.

to post comments

MIR is a wiser choice

Posted Sep 1, 2020 21:54 UTC (Tue) by mkubecek (subscriber, #130791) [Link] (8 responses)

"no requirement for doing the same" is not nearly enough, if rust in kernel is to be considered, it should rather be "guarantees that it cannot happen". And even then I would be very unhappy about the prospect of mixing a new language with very different logic into C codebase (and adding dependency on its toolchain).

MIR is a wiser choice

Posted Sep 1, 2020 22:17 UTC (Tue) by roc (subscriber, #30627) [Link] (7 responses)

This is pretty easy to satisfy. With the "clippy" tool you can easily implement custom lints to restrict the use of new language features, and run those in CI. For a project like the kernel you eventually want custom lints anyway.

Another approach would be to have a CI checker that simply runs "cargo check" (or the equivalent if you're not using cargo) with a fixed version of a compiler.

MIR is a wiser choice

Posted Sep 2, 2020 6:07 UTC (Wed) by edomaur (subscriber, #14520) [Link] (6 responses)

In fact, it's the same as with GCC : the kernel require a specific version of a compiler, it can/should be the same with rustc, anchoring the Rust kernel code to a specific version.

MIR is a wiser choice

Posted Sep 2, 2020 6:42 UTC (Wed) by roc (subscriber, #30627) [Link] (5 responses)

rustc is different because they don't provide updates to any compiler branches other than the current release, so using a fixed release indefinitely to generate shipping code is not a good idea.

MIR is a wiser choice

Posted Sep 2, 2020 10:39 UTC (Wed) by vomlehn (guest, #45588) [Link] (4 responses)

Every real project I've worked on reached a point where there were specific stability points, e.g. git branches. Only bug fixes get added to the branches. This is the way the kernel stable releases work. I would expect the same to emerge shortly for Rust as pretty much all Rust users are going to required it. It's nothing fundamental to Rust.

MIR is a wiser choice

Posted Sep 2, 2020 22:49 UTC (Wed) by roc (subscriber, #30627) [Link] (3 responses)

There are large projects where the number of stable branches is very small and and the duration for which they are maintained is not very long. E.g. for Chrome there is only one stable branch and it is maintained for no more than six weeks. For Firefox there are two and the longer one (ESR) is maintained for one year. I believe the Google monorepo never has a stable branch.

I see no reason why Rust will need long-lived stable branches.

MIR is a wiser choice

Posted Sep 3, 2020 6:04 UTC (Thu) by edomaur (subscriber, #14520) [Link] (2 responses)

> I see no reason why Rust will need long-lived stable branches.

For embedded systems certification it will be needed, specially in telecom and medical areas. For example, some times ago I used Telit GSM modem which had a Python interpreter available inside, but even if the current Python was already 2.7, the provided interpreter had to be a v1.5.8 because of the time it took to pass the certification. And in the medical world it's even worse than that.

To be honest, I think that the Rust community will add an LTS version for the purpose, sometime in the future, but it's not the priority at the moment.

MIR is a wiser choice

Posted Sep 3, 2020 22:43 UTC (Thu) by roc (subscriber, #30627) [Link] (1 responses)

Ah yes, you're right about that domain. I guess you're talking about Sealed Rust attempting to meet that need: https://ferrous-systems.com/blog/sealed-rust-the-pitch

MIR is a wiser choice

Posted Sep 6, 2020 7:13 UTC (Sun) by edomaur (subscriber, #14520) [Link]

Ah, yes, I forgot Sealed Rust but it's exactly why I meant.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/830293/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy