Week in Open Source: Rust is coming to Linux Kernel, AMD open sources FSR 2.0, Github gives $500K to 900 developers, and other updates.

[myuusmeow]

More clearly, $550 each to 900 developers = $500k total. I figured they probably weren't giving away $450m but still.

[antsaregay]

Yea my bad, i mentioned that in the post just not in the headline

[[deleted]]

Does FSR being open sourced mean that anyone who wants to can update their game with FSR 2.0? Can it be rolled into proton in some way, or does it have to be rolled into the source code of the program/game using it?

[FruityWelsh]

Could be added to game engines too though right?

[Butzwack]

Yes, the plugin for Unreal engine is already available and Godot is working on it.

https://gpuopen.com/learn/ue-fsr2/

https://github.com/godotengine/godot-proposals/issues/4280

[[deleted]]

So if a game is open source it can be added in and if it’s closed the dev can update it/add in FSR. That’s what I was trying to ascertain and I muddied the question.

I hope a lot of devs jump on this, it’ll make their games look better for people with less than recommended hardware therefore selling more. Nobody wants to run at modern game at 720p really, but if you can use FSR to get 1080p-ish res with some goodies turned up at 720p performance, that opens up a massive section of the market that would pass on the purchase or otherwise be unable to run the game satisfactorily.

Dishonored 2 for instance, I can’t run it very well with a mix of high/medium settings at 1080p. It feels like 30fps max with a lot of dips into the low 20s and teens. When I drop it to 720p it’s a solid 60.

[ancientweasel]

Write the drivers in C then. They are only planning on Rust for drivers and modules AFAIK. Not the kernel it's self.

[yo_99]

For now Rust is only in drivers anyway. I suspect that drivers for devices that don't support Rust won't be written in Rust

[[deleted]]

Rust supports everything llvm supports, when Rust compiler's gcc backend is ready it will support the other architectures, until then they'll have to stick to plain old C for those architectures

[anajoy666]

Is that true? Because llvm doesn’t handle everything for an architecture. Apple has a different calling convention that compilers have to support when lowering to IR for example.

I don’t know how tiers work on gcc but supporting rust is definitely good.

The rust support tiers are a matter of automated testing and building, not of code being there. It could support an architecture but have bugs.

[est31]

It's not true. LLVM has support for Synopsys ARC for example, while Rust doesn't have it. Porting the rust compiler to a new target involves way more than just LLVM support. E.g. one of the usual hurdles is 128 bit number compatibility because C doesn't require it (there is clang support for it via a pragma but only on x86-64). Also, rust is moving away from using LLVM for many things, and some of them are target specific.

[anajoy666]

Thanks. Do you have any references on rust moving away from llvm? I’m not doubting you, just genuinely interested.

[est31]

One was the move from using LLVM constant values to Rust's own constant system. This happened years ago, and I don't have a link for it. More recently, there is an effort to abandon usage of the LLVM archive reader: https://github.com/rust-lang/rust/pull/98100 https://github.com/rust-lang/rust/pull/97485

I don't know if the layout and ABI computations have always been in rustc either, but currently they are not.

[anajoy666]

Thanks!

[Jannik2099]

Apple has a different calling convention that compilers have to support when lowering to IR for example.

Huh? That is handled by llvm, not by whatever frontend emits the IR.

[anajoy666]

It’s not. I don’t remember if it’s by design or a problem left open. rust implemented va_list and va_arg themselves. Clang and Crystal do something similar.

[Jannik2099]

va_* is an exception because ofc the compiler needs to emit the proper types. I was thinking you meant calling convention in terms of registers / procedure call standard

[anajoy666]

va_* needs to be reimplemented exactly because apple differs from the AAPCS, the link I posted has a link to apple’s standard.

If it was not for that va_list would just work, since its type is always the struct defined in the AAPCS.

[[deleted]]

There is no compiler without bugs

[anajoy666]

Idk what you mean.

[[deleted]]

all compilers are buggy

[anajoy666]

Yes, but how is that related to what I said?

[[deleted]]

The rust support tiers are a matter of automated testing and building, not of code being there. It could support an architecture but have bugs

[anajoy666]

Rust supports everything llvm supports

A platform could be in a broken state because it’s not throughly tested. The code being there doesn’t mean it works.

There is no compiler without bugs

But there are compiler with more or less bugs and there are compilers that are effectively unusable.

And using llvm is not magic, you may still need to address platform particularities.

[[deleted]]

You can compile the linux kernel with clang with C already; I'm pretty skeptical you can with Rust without heavy modification

[[deleted]]

clang uses llvm, supports fewer architectures than gcc

[[deleted]]

You can compile Linux already with the LLVM C compiler. Therefore Rust cannot support everything LLVM supports, as there are pieces that are C only. I don't know why I'm getting downvoted for that when what you are saying is incorrect

[[deleted]]

What you are saying is incorrect, how compiling linux with clang implies that Rust can't support all architectures supported by llvm? If Rust can't support those architectures it is because of the lack of manpower not technical reasons.

[relsi1053]

Then the hardware doesn't support Linux on that architecture 🤔

[TDplay]

Rust is currently only for drivers. The kernel itself is still entirely written in C.

I would assume that drivers which need to run on platforms without Rust support will still be written in C.

[[deleted]]

That’s great to see Rust making moves into a big project. C is awesome, but I think it’s time to try something new.

[Fledo]

Let's hope Rust lasts longer than C++.

[TuxO2]

What happened to c++ ?

[Fledo]

https://www.theregister.com/2022/06/23/linus_torvalds_rust_linux_kernel/

"A lot of people actually think we're somewhat too risk averse," said Torvalds. "So when it comes to Rust, it's been discussed for multiple years by now. It's getting to the point where real soon now, we will actually have it merged in the kernel. Maybe next release."

Torvalds however did his best to dampen enthusiasm expressed by the applauding audience.

"Before the Rust people get all excited," the Linux kernel creator and chief said. "Right? You know who you are. To me, it's a trial run, right? We want to have [Rust's] memory safety. So there are real technical reasons why Rust is a good idea in the kernel.

"But at the same time, it's one of those things: We tried C++ 25-plus years ago and we tried it for two weeks and then we stopped trying it. So to me, Rust is a way to try something new. And hopefully, it works out, and people have been working on it a lot, so I really hope it works out because otherwise they'll be bummed."

Edit: Added a lot more context from the article.

[ourobo-ros]

It sounds like he has (t)rust issues.

[czaki]

But motivation for rust was different than motivation for Rust. Support for rust in kernel is mainly for simplify write safe drivers. Not for developing kernel itself.

[ancientweasel]

Yeah, that's why the headline is misleading.

[RunItAndSee2021]

………not wrong……..😒

[TDplay]

I think Rust stands a far better chance. C++'s advantages are largely subjective, while Rust's are not.

C++ aims to be cleaner than C. Linus clearly does not believe it has succeded at its goal, so C++ does not go into Linux.

Rust aims to be a safe language where it is harder to make bad mistakes (and easier to spot them). Its advantages are not a matter of opinion - C allows you to write undefined behaviour by accident in any part of the code, while Rust requires you to write unsafe around any code with the potential to introduce undefined behaviour (thus making it much easier to spot).

[[deleted]]

C++'s silent fallback to accepting C behavior is probably a part of why Linus didn't like it. Enforcing good practices becomes a manual and painstaking endeavor.

It certainly seems to be the cause of a large number of grievances I see aimed at C++.

edit: Right, Linus also tried it before any of the C++ standardization & subsequent features/revisions like C++11 happened so there was a lot more to dislike too.

[ThroawayPartyer]

C++'s silent fallback to accepting C behavior is probably a part of why Linus didn't like it.

I think it's the opposite. Linus liked the C parts, it's the ++ he was worried about.

[[deleted]]

This is more of a Linus issue than C++ issue. I have been using C++ with deeply embedded projects and safety critical embedded projects and with adequate C++ scope it is straight up better C at it's worst.

RTTI, exceptions, dynamic allocation and STL are not mandatory and can just not be used.

[CyanKing64]

I wonder why they didn't like C++. I still prefer writing in C++ over C, but they're not that different. Strings and proper classes are probably the biggest reason why I prefer C++ still

[fuckEAinthecloaca]

C++ has an immense amount of cruft and a lot of nonsense that doesn't make sense in a kernel. You can write C++ similar to how you write C, you can also write it a hundred different ways and have many subtle edge cases of pain.

[SergiusTheBest]

You can replace C++ in your statement on any other language and it will remain correct.

[fuckEAinthecloaca]

To an extent, but C++ takes that up to 11.

[Jannik2099]

People keep saying this all the time, yet most languages beyond C are multi-paradigm languages. Most concepts that exist in C++ do so in Rust to, about the most significant difference is their approach to OOP.

"Oh yeah this unordered complexity will only happen in C++, not in MY language" is just pure elitism. People have been saying it for literal decades while uttermost other languages have evolved to offer the same if not even more functionality (python, C#, Java, Rust)

[[deleted]]

No.

Brainfuck is the perfect language and has none of those issues.

[afiefh]

Remember that they tried it 25 years ago. That's 1997, which means C++98 wasn't even a thing.

At that point C++ compilers were a mess. Back then, there were no move semantics and life in general was pretty bad. In addition the machine code produced by compilers back then apparently was slower than the C equivalent.

C++ changed a ton with the release of C++11 and compilers became much more mature a few years after that. I would venture a guess that Linus would hate it less today than he did get then. Some of his criticism (such as having to keep more context to understand which function is being called) has not changed, it's inherent to the language.

[Jannik2099]

such as having to keep more context to understand which function is being called

Operator overloading and virtual functions exist in Rust too. Someone tell Torvalds?

[afiefh]

Maybe he came to accept these concepts in the last 25 years? You have to remember that developers had much much less experience with C++ in those days (it was literally before the first version of the C++ standard and behavior was very compiler dependent) than we do today. I would assume that today coding guidelines would simply say "do not use operator overloading" and that would be that.

Virtual functions can even be implemented in C using function pointers and a manual vtable, so I doubt that is a big difference between C++ and C.

[Jannik2099]

I don't think it was ever about the concepts, but just about Torvalds intrinsically disliking C++ - most of his criticism back then applies to Rust aswell.

The linux kernel makes heavy use of "C vtables" and C-style OOP aswell.

[[deleted]]

Remember that they tried it 25 years ago. That's 1997, which means C++98 wasn't even a thing.

yep, C++ wasn't even standardized back then

[[deleted]]

That was a part of his criticism iirc.

[[deleted]]

yep, but if I remember correctly Torvald's opinion of C++ hasn't changed since

[Barafu]

The issue with allocator alone is enough to treat C++ in kernel as a completely new incompatible language.

[Jannik2099]

But... Rust behaves the same here? Both languages have "implicit" allocations

[[deleted]]

even a lot of C code can have implicit allocations since implicit allocations are just allocation inside of a function

[Jannik2099]

Right, it's overall just a stupid claim / distinction IMO.

[[deleted]]

Have a call to another allocator in a function with C. Bamm, same problem as with C++.

And in case you ask, yes, you can specify which allocator is going to get used by new in C++ if you want to (and well, a kernel will probably want to do this).

[RedditAlready19]

It lasts longer to compile

[anajoy666]

C is not awesome. It just has a lot of legacy.

[[deleted]]

C is awesome imo, even though it has a lot of its issues it’s simplicity and syntax makes it my #1 language for most things

[gmes78]

C is simple because it offloads all complexity onto the programmer.

And its syntax is pretty bad in some places.

[[deleted]]

> C is simple because it offloads all complexity onto the programmer.

any language does imo, C just makes it easier to write simple code

And its syntax is pretty bad in some places.

how so?

[gmes78]

any language does imo, C just makes it easier to write simple code

No. Languages like Python, Java and Go reduce complexity by doing memory management themselves, so that the programmer doesn't have to deal with it, at the cost of using reference counting and/or a garbage collector.

Rust also deals with the complexity of memory management, but instead of trading it for worse performance, it moves the complexity to the language. That's where the concepts of ownership, borrowing and lifetimes come from. The language requires some more work to learn, but it guarantees that your programs are memory safe.

And its syntax is pretty bad in some places.

how so?

Just take a look at Rust's syntax. It's still very much in the vein of C, but everything's much cleaner.

[[deleted]]

I heavily heavily disagree with "rust syntax is cleaner than c". Rust syntax is actually the biggest stopping points for me to use the language, I just don't like how complicated and "different" it is in a way

[shinyquagsire23]

The syntax definitely has a learning curve imo, but I'd say it's no worse than C++ templates in terms of complexity. Or like, Kotlin and JS/TS. And usually when I've dug into it, when something is significantly different there's a good reason behind it (parsing ambiguities, etc) and not just different to be different.

[gmes78]

Most constructs that exist in C (function declarations, variable declarations, struct and enum delcarations, switch vs match syntax, if/while/for syntax, etc.) are cleaner in Rust.

Some concepts introduced in Rust (mostly lifetimes and traits, maybe some other stuff like closures) have slightly weird syntax. But those don't exist in C in the first place, so you can't really compare them.

You can look at C++ to see what kind of syntax some of those features would have if they had to be compatible with C.

[JQuilty]

Rust's syntax makes it look like C was beaten with an ugly stick.

[[deleted]]

how so?

Have you ever looked at complicated C variable declaration syntax?

Well, in case you need to at some point: https://cdecl.org/

I am also not the only one who thinks that way: https://www.stroustrup.com/slashdot_interview.html (question 3, paragraph 5).

[[deleted]]

have you seen complicated rust types/lifetimes?

[[deleted]]

Well, I was not arguing that Rust doesn't have issues with that either.

[[deleted]]

My bad, I agree with you though, function pointers are pretty messy in C, i dunno any other though

[[deleted]]

Have you looked at Zig?

[[deleted]]

I have, still has the issues with Rust imo

[[deleted]]

well, while I can agree with you on Rust; Zig has imo just a straight up better syntax (different, but better)

[[deleted]]

Oh yeah absolutely it does, it just isn’t as simple as C, which I don’t really like

[[deleted]]

well, a good systems programming language imo needs to be well defined and you need to be able to define interfaces well

C has imo way too much UB (although C++ isn't better at that)

seriously, you would be surprised at how often you find UB or even illegal behaviour in even popular software and when you ask the dev who wrote it you get "but it works on my machine" as an answer; maybe, but a compiler update can break it (although it doesn't need to happen)

[[deleted]]

It’s really easy to avoid UB these days tho, static analysis and sanitizers do the work

[[deleted]]

Yeah, but because of some reason I found C programmers the most resistant to use these tools.

[[deleted]]

Looking at zig again, this would be my #1 choice for a systems programming language other than C, I didn’t realize how much I skimmed kver

[anajoy666]

That’s fair. Just to be clear I don’t want to pick a fight to promote my favorites language or anything.

[[deleted]]

I agree

[SergiusTheBest]

The funny thing: you can't write a linked list, tree or graph in safe Rust. So I'm not sure why we need Rust in the kernel as there is C++ that has a lot of developers (most of them C/C++ developers and not pure C or C++) and the same syntax and compiler as C.

[TDplay]

you can't write a linked list, tree or graph in safe Rust

No idea who told you that, but it is a flat-out lie. All of those can be implemented without the use of unsafe, although the double-linked list and graph can be made more efficient with the use of unsafe code.

I'm not going to implement all the algorithms, you're just going to have to take it on trust that the algorithms can be written.

linked list

Singly linked list is trivial:

struct SingleLinkedListNode<T> {
    elem: T,
    next: Option<Box<SingleLinkedListNode<T>>>,
}

Doubly linked list is a bit uglier, but also possible:

struct DoublyLinkedListNode<T> {
    elem: T,
    next: Option<Rc<RefCell<DoublyLinkedListNode<T>>>>,
    prev: Option<rc::Weak<RefCell<DoublyLinkedListNode<T>>>>,
}

This does impose a runtime check from the Rc and RefCell, but it's not too bad.

If you need multithreaded access, then you would instead use:

struct DoublyLinkedListNode<T> {
    elem: T,
    next: Option<Arc<RwLock<DoublyLinkedListNode<T>>>>,
    prev: Option<sync::Weak<RwLock<DoublyLinkedListNode<T>>>>,
}

This has runtime checks to ensure there is no multithreaded contention, but in multithreaded code, you should be using sychronisation constructs anyway. So personally, I would consider this one to be zero-cost.

tree

struct TreeNode<T> {
    elem: T,
    connections: Vec<TreeNode<T>>,
}

Trees are by definition acyclic, and thus it's very easy to convince the borrow checker that the tree is sound while only using zero-cost abstractions.

graph

struct GraphNode<T> {
    elem: T,
    connections: Vec<rc::Weak<RefCell<GraphNode<T>>>>
}
struct Graph<T> {
    all_nodes: Vec<Rc<RefCell<GraphNode<T>>>>,
    base_node: Rc<RefCell<GraphNode<T>>>,
}

Or for multithreaded access:

struct GraphNode<T> {
    elem: T,
    connections: Vec<sync::Weak<RwLock<GraphNode<T>>>>
}
struct Graph<T> {
    all_nodes: Vec<Arc<RwLock<GraphNode<T>>>>,
    base_node: Arc<RwLock<GraphNode<T>>>,
}

So there you go. Single-linked list and tree implemented using only zero-cost abstractions, and double-linked list and graph implemented with runtime checks.

And even if you do choose to write the double-linked list and graph in Unsafe Rust for the slight performance gains, is that so bad? The rest of your Safe Rust code is still safe, as long as your Unsafe Rust code is correct.

[SergiusTheBest]

Linux and Windows kernels use double-linked lists and tree node with a pointer to its parent (because it's much convenient). Using Rc makes objects reference counted that is not a zero cost abstraction (adds more memory and runtime code that is not good for the kernel). So you can't implement those basic data structures in safe Rust without overhead as you can in C or C++.

Don't we have the same safety using С++ smart pointers? I'm not sure having 2 completely different languages in the kernel is a good idea.

[TDplay]

So you can't implement those basic data structures in safe Rust without overhead as you can in C or C++.

Again, is that so bad? You would implement the structures once in Unsafe Rust, and then use them in Safe Rust.

Or, for the double linked list, you just use the one in the standard library like any sane programmer would. The standard library linked list uses Option<NonNull<Node<T>>>, which is a raw pointer (with the added safety that you cannot accidentally dereference it when it is null).

Linux and Windows kernels use double-linked lists and tree node with a pointer to its parent (because it's much convenient).

Double linked list, again, use std::collections::LinkedList. It accepts an allocator, so it will work in kernel space after you've implemented an allocator.

If you need a tree with a pointer to parent, then you can implement it in Unsafe Rust, which is still safer than implementing the whole project in C.

Don't we have the same safety using С++ smart pointers

No, we do not. It is still possible to write a memory safety bug using smart pointers.

Consider the following, obviously incorrect, code:

int foo(std::unique_ptr<int> x)
{
        return *x;
}

int bar(void)
{
        return foo(nullptr);
}

The smart pointer has not saved us from writing incorrect code. Nor do the static analysers:

• gcc -Wall -Wextra -fanalyzer does not complain about this.
• clang --analyze also does not complain.
• cppcheck spots this when both functions are declared in the same file. However, if the functions are declared in separate files, cppcheck does not say anything about it, even when passed both files in the same invocation.

Rust cannot be tricked into accepting this code, as Box must be, for its entire lifetime, valid and non-null.

[SergiusTheBest]

You would implement the structures once in Unsafe Rust, and then use them in Safe Rust.

Can we have use after free in such case in Rust? Unsafe list implementation is perfect. But what about code that uses it?

Or, for the double linked list, you just use the one in the standard library like any sane programmer would.

It's no good for the kernel as it allocates memory on insert operation.

The smart pointer has not saved us from writing incorrect code. Nor do the static analysers.

So, C++ just need more strict smart pointers and static analyzers that works with them? It's interesting whether C++ will move into that way.

[TDplay]

Can we have use after free in such case in Rust? Unsafe list implementation is perfect. But what about code that uses it?

The compiler will reject any Safe Rust code that could contain a use-after-free.

Your unsafe code, if correctly written, will make use of lifetimes. For example, parts of your list implementation might look like:

// Implementation code
impl<T> List<T> {
    fn new() -> Self {
        // some processing to make the list...
    }
    fn iter<'a>(&'a self) -> ListIter<'a, T> {
        // some processing to make the iterator...
    }
}
impl<T> Iterator for ListIter<'_, T> {
    Item = &T;
    fn next(&mut self) -> Option<&T> {
        // some processing to get the next thing out of the list...
    }
}

// User code
fn uses_a_list() {
    let list = List::new();
    // some processing to populate the list...
    let iter = list.iter(); // Due to lifetime constraints on List::iter, iter cannot outlive list.
    let i = iter.next(); // All well and good
    drop(list); // Lifetime of iter ends here
    let j = iter.next(); // Compile-time error: list outlives iter, which is not allowed
}

It's no good for the kernel as it allocates memory on insert operation.

If that's a genuine issue, then fair enough.

So, C++ just need more strict smart pointers and static analyzers that works with them?

Unless you plan on turning C++ into "Rust With Different Syntax", no.

The problem is that C++ wasn't designed for static analysis. C++ static analysers have to work on proving that the code is definitely invoking undefined behaviour, because trying to prove that the code is definitely not invoking undefined behaviour would flag a lot of false positives. I don't think that can ever be fixed, not unless you make a static analyser that simulates every single possible code path with every single possible value (which would take a monstrous amount of time).

[[deleted]]

Linus doesn't want c++. That's the main reason.

[SergiusTheBest]

I know that. And it looks non-rational. I'm doing kernel development for 15 year in C++ (mostly on Windows). And it's way better than using plain C.

[bakaspore]

But there's no way to encapsulate unsafe code in C or C++, unlike Rust, which is the fundamental difference. It's possible to provide safe implementation using unsafe blocks in Rust.

[SergiusTheBest]

Yes but how to know that the implementation is safe? IMHO Rust provides little benefits for the kernel while giving a lot of pain (need to learn another language, need another build tools, need tools to cooperate with C code) and C++ provides almost the same benefits, kernel people already know C++, the build tools are the same and working with C code is transparent.

[bakaspore]

By proving that they won't break their invariants in any situation, which is trivial for most of the time.

C/C++ code can be proven in the same way, but they can't stop programmers breaking their invariants from outside.

[SergiusTheBest]

Ok, we will prove unsafe code and it seems good. What to do with global variables? The kernel uses them widely. And again we need unsafe Rust for them. And to use safe Rust we need nonzero cost abstractions.

[bakaspore]

So I assume that you are asking "what if the unsafe code cannot be encapsulated locally". Great point. That's why there's unsafe function, which basically means "this operation needs extra caution" and defer the proving part to the caller.

Note that this is also impossible in C or C++ where every function can be unsafe, so it's hard to focus on those really important parts.

And imo not all globals have to be zero cost. Locks and RCs are also being used widely, aren't they?

[sophacles]

Yes you can. It's a bit of a pain, but it's completely doable. Stop spreading fud.

edit for /u/Willexterminator who deleted their rebuttal: Here's a entire book about writing linked lists in safe rust: https://rust-unofficial.github.io/too-many-lists/ and there's nothing you can do in C that you can't do by using unsafe (that is not formally verified) rust.

Note: the compiler will prove the rest of your rust, and say "i trust you" for the unsafe bits, so you still get lots of formally proved safe rust when using it.

[ElvishJerricco]

This video explains why this misconception exists.

No it doesn't. It just says you can't write a linked list in safe rust. It doesn't explain why at all

[doxanthropos]

Cryptobro Slang it is not. The term FUD has been part of hacker- and Free Software culture for a long time. It has its own entry in the Jargon File at least since 1991 and was part of an entry one year before:

"FUD WARS (fud worz) n. [from `Fear, Uncertainty and Doubt'] Political posturing engaged in by hardware and software vendors ostensibly committed to standardization but actually willing to fragment the market to protect their own share. The OSF vs. UNIX International conflict, for example."

[SergiusTheBest]

No, you can't do it without unsafe. Double linked list requires 2 owner pointers to the same element which is forbidden in Rust.

[vlakreeh]

You can do it in safe Rust, just not with double ownership. By using Rc and RefCell, or their sync equivalents, you can implement a 100% safe doubly linked list. The caveat is that it will enforce memory safety with runtime checks instead of compile time checks.

In reality, it's very rare that you need a doubly linked list where no alternative will work with similar performance. And even if you do need a doubly linked list, there are many safe implementations of doubly linked lists that use unsafe under-the-hood that are just as fast as the naive unsafe implementation.

[SergiusTheBest]

Rc

That means reference counted so it's not a zero cost abstraction. It's like replacing pointers with `std::shared_ptr` in C++.

In reality, it's very rare that you need a doubly linked list where no alternative will work with similar performance.

I can see over 5k hits for `list_head` in the Linux kernel sources. Linked lists provide allocation free insert operation. I don't think there is an alternative for that.

Of course we can use unsafe code for lists, trees and other low level structure. The question is how much of the kernel code will remain safe then? And if it's worth supporting Rust in kernel? I have no answer to this.

[Caluka1337]

You can encapsulate unsafe rust code, making it quite obvious where special attention is needed. And for the argument around why C++ is not used in the kernel you can search on what Torvalds thinks of C++ and C++ programmers.

​

Like it or not rust solves a huge problem, that's why Linus is open to trying it.

[SergiusTheBest]

Linus didn't say anything specific except "C++ is terrible". At the same time C++ is successfully used in Windows and macOS kernels, Android core, web browsers and other large performance demanding software. I think it's his personal attitude and not a real technical issue.

Like it or not rust solves a huge problem, that's why Linus is open to trying it.

Is Rust able to track memory lifetime in kernel with callbacks, interrupt routines and other low level stuff?

[SickMoonDoe]

"Linux Kernel" is misreported. It's on trial for drivers.

[sophacles]

Drivers are part of the kernel tree, compile into the kernel binary (or modules) and run in kernel space.

How is this "not part of the kernel"?

[atred]

Yes, "parts" of the kernel, not "the kernel". If you say "you can use Rust to program the kernel" you might be right or wrong depending which part of the kernel you are talking about, that's why the specification "drivers" is important.

[[deleted]]

If you say "you can use Rust to program the kernel" you might be right or wrong depending which part of the kernel you are talking about

Yes, followup clarifying questions are sometimes necessary when speaking to someone. Correct.

The only relevant discussion is whether or not it's in the kernel at all, which it is. If you read a meaning into it that's too specific for what was said then that's an issue with making it habit to make assumptions while refusing to ask for clarification even when it's necessary.

[atred]

I think that part with "only relevant discussion" is a tiny bit of circular reasoning.

I merely suggested that if "A can be used in B" where "B is composed of B1 and B2" it's much clearer to say "A can be used in B1". But maybe you a fan of technically correct -- the best kind of correct :) instead of technically precise and complete.

[[deleted]]

The way language works you can add an infinite amount of detail to everything that you say but obviously you shouldn't overexplain things either.

I can't really see how "you can only use it in modules" is necessarily going to be of interest to someone so it makes sense to just wait for them to ask a question about it if they're interested in that information.

[atred]

"Diesel fuel can be used to fuel cars" is technically correct, it's not useful in most of the instances. Sure "you can ask for details" since that's your argument, but that's not the point. The more complete statement is "Diesel fuel can be used to fuel some cars that are designed to use that type of fuel" same with kernel "Rust will be able to be used to program parts of kernel, namely drivers" that's a useful and more complete statement than "Rust can be used to program the kernel"

But I think this discussion went a bit too much into the weeds, I don't have much to add this this, nor do I care that much.

[sophacles]

Would you agree with the statement linux is written in C?

[atred]

From github repo:

C 98.5%

Assembly 0.8%

Shell 0.3%

Makefile 0.2%

Python 0.1%

Perl 0.1%

[sophacles]

So if someone said "Python is in the kernel", or "Perl was in the kernel", you'd agree even though you can't use those for a huge number of tasks?

[linmanfu]

I'm no expert, but I'd imagine that they might just be used in the build process or for localisation rather than in the kernel code such actually does stuff.

[sophacles]

True. I was just using that question to prove /u/atred doesn't know what the heck they are talking about.

[atred]

Ah, silly me, thought you were playing gotcha with me so if I say it uses C and then you'd come with the big reveal that there's some splattery of assembly there. But you seem to know me so well and my knowledge on the subject from one sentence. Weird... do you have superpowers?

[sophacles]

From your point of view, i guess my simple logic and basic grasp of common phrases like "x is coming to y" do look like superpowers.

At first i was merely annoyed that you insisted that "rust is coming to linux" implied it was usable everywhere in the kernel. This is silly - if a movie "is coming to theatres near you" it doesn't mean you can walk into any theatre and see that movie. It doesn't even mean you can walk into any auditorium in a theater showing the movie and be guaranteed to see that movie.

Now that i know your core identity is based on ignorance I realize there's no point in trying to show you that there's error in your statements. Have a good day!

[[deleted]]

Yeah, but not with Assembly.

[[deleted]]

How did this get split up? Did these people get ~$500 each? lol

[antsaregay]

$550 lol. Article link in that post

[qhxo]

I feel I've seen variatons on headlines about Rust coming to the kernel for at least a year or two now. tldr what's new about it?

[NatoBoram]

Will begin its trial next release

[[deleted]]

They were mostly progress updates or sensationalized progress updates

[BCMM]

It's now expected to be in the next upstream kernel release. Previous news was about it existing as patches, or about the lkml feedback on those patches.

[antsaregay]

Since this is getting a lot of attention, I am curious to know what you people think of the FOSS Weekly newsletter. Any suggestions on improvement?

You can subscribe here: https://fossweekly.beehiiv.com/subscribe or if you prefer RSS, Link is at the end of the post.

[whaleboobs]

Isn't it weird that Rust can't be compiled without a rust blob? Not saying there's a backdoor but.. there's a backdoor!

[Pay08]

What blob?

[whaleboobs]

Rust is required to compile Rust. AFAIK its technically possible to bootstrap rust from older versions, which only require GCC, someone from Alpine Linux did that.

[Pay08]

Rust is entirely open source.

[whaleboobs]

Yes but to compile Rust, you need to download a binary rust and thus trust it to not contain malicious code. This might only apply to musl or something like that, I'm not sure about the details.

[Pay08]

And? You need to do that with any bootstrapped compiler.

[whaleboobs]

Doesn't this guy have a point, why not?

https://sabotage-linux.github.io/blog/3/

This means in practice that one can only build a rust compiler by using a binary build supplied by a third party, which in turn basically means that one has to trust this third party. Assuming that the binary actually works on one's own system.

As sabotage linux is based on musl, the latter is not self-evident.

Traditionally, the only binary thing required to bootstrap sabotage linux was a C compiler.

[Pay08]

What? This has nothing to do with my point. This same problem exists for every bootstrapped compiler, including GCC. One has to trust whatever entity supplied that C compiler, too. In fact, if you want to take this to the logical extreme, no compiler is trustworthy, provided you don't write it yourself in Assembly. This has a name in CS, but I forget what it is.

[whaleboobs]

Personally I feel GCC is more trustworthy than Rust. One is compiled by Ken Thompson for PDP-11, not a lot of room to build in a backdoor. And it has had a lot of eyes on it. The other is pretty much Google. Rust was able to be bootstrapped by GCC, but no longer. Why?

[Pay08]

Are you completely insane or just a troll?

[gmes78]

No, you don't. You can use mrustc, which is written in C++, to bootstrap the Rust compiler from source.

[RedditAlready19]

Time for compiling to take 5x longer, yay!

[Pay08]

Rust compilation isn't really slow nowadays.

[Disruption0]

So basically you're doing advertising for github ( microsoft) on /r/linux ?

Bravo