@kornel that could be feasible in constraints if they did not break ABI purposely. They’ve documented that even as a feature. Changing symbol mangling is ABI annihilation. Should have never touched that.

@leeloo @vathpela Oh no, even mangling is not sealed but has versions: "Mangling versions'. For unmangled symbols you can even script some binary analysis tasks. Rust's language team takes apparently care that binary analysis is not only more complicated but also any automation on that will also break over time.

@leeloo @vathpela Here's at least an example https://doc.rust-lang.org/rustc/symbol-mangling/index.html

NIST said it has awarded a new contract to an outside vendor that will help the federal government process software and hardware bugs added to the National Vulnerability Database (NVD).

NIST wouldnt say which vendor was hired

https://therecord.media/nist-nvd-backlog-clear-end-fiscal-2024

@lorddimwit Nothing against Zig but we apparently chose Rust.

I still think we should fork Rust and strip it down like hell. Then it would not be compatible with Rust but more like relative. I don’t see any problem in that I mean even C is not at least formally a subset of C++, they have some differences in semantics

I don’t care about languages (except little bit of C which is lingua franca for ABI) but I’m more like worried:

1. Experienced maintainers in file systems, mm etc. with no time at hands are not able to do proper analysis on Rust. So we are going to the unknown without “shared consensus” being on the steering wheel.
2. It has tons of “never use this in kernel” crap, which we IMHO should just remove from it. Who care if we end up something NOT Rust but still relative or similar to Rust.
3. Language spec is out of control… and in Github ;-)
4. Compiler bugs are a disease. That huge ever growing language spec maintains their steady flow.
5. It will be tedious job to maintain correspondence with gccrs and rustc. Even if you think that LLVM should be everywhere (which is no-go for linux but just for the sake of example), how do you do ever detect all those nasty compiler bugs?

We need something more compact that does not change often so that also compiler’s implementation can be matured, bugs fixed etc. So yeah, to sort out this madness I really do personally (this is my voice only, not korg as org) think that we should stop this madness and just do a fork and control all that in kernel mailing lists. Linux would deserve language of its own, relative to Rust but not always compatible…

@leeloo @vathpela

Yes all that crap piles up to put short. Read about binary analysis, compilers, linkers, ELF ABI specs etc. and you should get a grip.

If Windows XP was released in 2024

@kornel Traits and generics would still need some mangling but limiting their features we could possibly get the symbols in the ELF binary have names that would be more familiar and meaningful and more C alike instead of following C++ convention like Rust does. Right and I think unwrap() should not exist as any default behavior is harmful, especially panic. So yeah there would be lot of stuff that could be simply wiped away and get a better language for kernel dev.

@kornel We could keep the features from Rust that make sense ofc and remove those that don’t and get a tighter language spec which is less prone to often ignored compiler bugs when discussing about safety properties. By freezing the language with a fork of Rust, it would be also easier to keep ”lustc” and ”gccls” in sync (if the fork was called ”lust” for the sake of example).

@kornel well for kernel we need only fallible allocations, namespaces could be taken away (and causes need for symbol mangling), no use for external crates, we don’t use cargo because vmlinux is self-contained, we don’t use rust’s atomic type. There’s alot of harmful features in Rust for kernel. Just randomly picked a few.

The worst part of any trip ongoing: departing home. The best part of any trip is yet to come: arriving home. ✈️

@vathpela Oh, and then we could run the development of language spec and the compiler frontends in total three mailing lists (e.g. lust-lang@vger.kernel.org, lust-gcc@vger.kernel.org and lust-llvm@vger.kernel.org).

Github makes following the language development with easy ways to backtrack years old discussons almost impossible or you really have to put effort to it vs. just going to lore and grabbing a mbox.gz of a relevant discussion.

I really wish I would live in this nice and lusty alternate reality instead of this crappy and rusty reality ;-)

A plea for more thoughtful comments https://lwn.net/Articles/975597/ #LWN

Here are the slides for a talk I just gave about using perf c2c to find cache line contention in postgres:
https://anarazel.de/talks/2024-05-29-pgconf-dev-c2c/postgres-perf-c2c.pdf

@vathpela And yeah C and Rust would be by definition bridged then. And language would be still familiar enough that knowledge of Rust would help to cope with it.

@vathpela There's only like 50-60 Rust files in total in the mainline so it would not be even tremendous job to initiate. Not whole a lot of legacy, and all of it is experimental features (e.g. given the lack of gccrs support cannot be turned on in arch defconfig).

@vathpela You could even ironically say that it would be Rust way of approaching open source: fork anything in existence and make Rust version out of it. Like even coreboot has a version called "oreboot"

@vathpela It might be.too radicalized thinking but sometimes I feel that maybe Linux should simply fork Rust and remove unnecessary stuff. We in any case do not want external dependencies for vmlinux so it would be for the most part just stripping of features. By removing e.g. namespaces we could simplify the equation of getting rid of name mangling. Also then there would not be a problem of having incompatible atomic, which applies actually both C and Rust.

And right, then the language could only have fallible allocations, not just as an additional feature but instead as an enforced pattern.

Not my decision but I do have right for an opinion at least. Let's call this fantasy language as Lust ;-)

@vathpela Yes, that was a rough cut, skipped relocations, GOT, PLT etc. ;-)