321–330 of 853 posts
Does this mean that all architectures that Linux supports but Rust doesn't are straight in the bin?
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,…
Earlier quoted context omitted.
Which ones would that be?
Some people talk about 68k not being supported being a problem
Rust also has an experimental GCC-based codegen backend (based on libgccjit (which isn't used as a JIT)).
So platforms that don't have either LLVM nor recent GCC are screwed.
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…
Pardon my ignorance but I find the claim "removing the nastiest cla ss of security vulnerabilities" to be a bold claim. Is there ZERO use of "unsafe" rust in kernel code??
Earlier quoted context omitted.
I don't think Perl comes pre installed on any modern system anymore
I am yet to find one without it, unless you include Windows, consoles, or table/phone OSes, embedded RTOS, which aren't anyway proper UNIX derivatives.
Earlier quoted context omitted.
I can’t think of many real world production systems which don’t have a rust target. Also I’m hopeful the GCC backend for rustc makes some progress and can become an option for the more esoteric ones
Commercial embedded OSes, game consoles, for example.
I’m sure if Rust becomes more popular in the game dev community, game consoles support will be a solved problem since these consoles are generally just running stock PC architectures with a normal OS and there’s probably almost nothing wrong with the stock toolchain in terms of generating working binaries: PlayStation and Switch are FreeBSD (x86 vs ARM respectively) and Xbox is x86 Windows, all of which are supported platforms.
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…
Pardon my ignorance but I find the claim "removing the nastiest cla ss of security vulnerabilities" to be a bold claim. Is there ZERO use of "unsafe" rust in kernel code??
In practice you see several orders of magnitude fewer segfaults (like in Google Android CVE). You can compare Deno and Bun issue trackers for segfaults to see it in action.
As mentioned a billion times, seatbelts don't prevent death, but they do reduce the likelihood of dying in a traffic accident. Unsafe isn't a magic bullet, but it's a decent caliber round.
Earlier quoted context omitted.
Don’t spread FUD, you can check some example code yourself. https://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/l...
Sorry but what have I said wrong? The nature of code written in kernel development is such that using unsafe is inevitable. Low-level code with memory juggling and patterns that you usually don't find in application code. And yes, I have had a look into the examples - maybe one or two years there was a significant patch submitted to the kernel and number of unsafe sections made me realize at that moment that Rust, in…
let's start by prefacing that 'production quality' C is 100% unsafe in Rust terms.
> Sorry, I am not buying that argument.
here's where we fundamentally disagree: you listed a couple dozen unsafe places in 1.5kLOC of code; let's be generous and say that's 10% - and you're trying to sell it as a bad thing, whereas I'm seeing the same numbers and think it's a great improvement over status quo ante.
Earlier quoted context omitted.
Don’t spread FUD, you can check some example code yourself. https://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/l...
Sorry but what have I said wrong? The nature of code written in kernel development is such that using unsafe is inevitable. Low-level code with memory juggling and patterns that you usually don't find in application code. And yes, I have had a look into the examples - maybe one or two years there was a significant patch submitted to the kernel and number of unsafe sections made me realize at that moment that Rust, in…
The unsafe parts have to be written and verified manually very carefully, but once that's done, the compiler can ensure that all further uses of these abstractions are correct and won't cause UB.
Everything in Rust becomes "unsafe" at some lower level (every string has unsafe in its implementation, the compiler itself uses unsafe code), but as long as the lower-level unsafe is correct, the higher-level code gets safety guarantees.
This allows kernel maintainers to (carefully) create safe public APIs, which will be much safer to use by others.
C doesn't have such explicit split, and its abstraction powers are weaker, so it doesn't let maintainer create APIs that can't cause UB even if misused.
Earlier quoted context omitted.
Swift does not seem suitable for OS development, at least not as much as C or C++.[0] Swift handles by default a lot of memory by using reference counting, as I understand it, which is not always suitable for OS development. [0]: Rust, while no longer officially experimental in the Linux kernel, does not yet have major OSs written purely in it.
What matters is what Apple thinks, and officially it is, to the point it is explicitly written on the documentation.
> Embedded Swift support is available in the Swift development snapshots.
And considering Apple made Embedded Swift, even Apple does not believe that regular Swift is suitable. Meaning that you're undeniably completely wrong.
[0]:
https://github.com/swiftlang/swift-evolution/blob/main/visio...