Rust in the FreeBSD kernel

epower53 said:
Seems like Rust is triggering folks, and I'd like to understand why.
Click to expand...
Rust is popular for memory safety, which sounds security-related, which sounds slower than not coding for the safety. I want max performance everywhere!

Or rather, I'm thinking most people choosing Rust aren't doing it for performance considerations primarily.

msplsh said:
If it didn't pose a threat, people would just ignore it.
Click to expand...
I'm not re-compiling stuff, so anything that gets Rust-ified later and potentially slower is out of my control.
 
Espionage724 said:
Rust is popular for memory safety, which sounds security-related, which sounds slower than not coding for the safety. I want max performance everywhere!

Or rather, I'm thinking most people choosing Rust aren't doing it for performance considerations primarily.
Click to expand...

Rust code shouldn't be noticeably slower than modern C++ using vectors (with bounds checking), unless the C++ developer excessively abused the stack in an unsafe manner or uses C arrays everywhere (no bounds checking).

Both C++ and Rust have many zero-cost abstractions.

I am not aware of any language benchmark to verify this. Benchmarking programming languages is hard and few people do it.

ETA: and then there is integer overflow/underflow checking, which you can turn on Rust, but for release builds it defaults to off. This is a massive safety gain and performance loss.
 
msplsh said:
If it didn't pose a threat, people would just ignore it.
Click to expand...
While I generally agree with the core of the statement, I'd like to add that rust folks make it really hard to just ignore it. They show up with an armored convoy, bash in your front door, strap you down on a chair and force you to listen to their ideas and opinions.

1760932427047.png


That is just my observations and in no way related to my liking or disliking of rust itself.
While I am interested in rust, half the time it feels like a forceful version of "do you have a moment to talk about our lord and savior?"
 
There are some very good technical reasons for not wanting rust introduced into the freebsd kernel. The central problem is the prospect of having a kernel half written in C and half written in rust, which is going to be a development and maintenance nightmare. Now you will need to know two completely different high level languages to work on the kernel, and have all the problems of interfacing between the two. Once it is in the kernel, there will be no way back. It's a recipe for disaster. Imagine trying to debug a path that passes through both C and Rust code; how hard do you want to make the problem for yourself?

The supposed benefits or rust are yet to be proven. Is software written in rust really any more secure than good quality C code? I doubt it. How many freebsd kernel developers really make elementary errors like writing buffer overflows into the code, that rust is supposed to save us from? How does freebsd manage to have uptimes of months or years if writing software in C is so riddled with programming errors caused by the supposed inadequacies of the language?

The Rust language is itself still under development, it is a moving target for developers. There are serious questions about the lack of a standard definition of rust; right now the one and only compiler "works as coded", there is no conformance test or compiler certification, and you hope that the compiler version you're using matches the book. The rust language has suffered instability and feature growth over the last 10 years; already you need to know which year's version of the compiler some arbitrary rust code was written for. There is only one compiler, so if major compiler bugs are found, there is no alternative available. All of which says that rust is still a computing research vehicle, rather than being an industrial strength software development tool like ANSI C.

I have nothing against rust itself, it clearly has some interesting ideas. The problem comes when you try to mix it in to an existing mature codebase written in a different language, especially an o/s kernel where it has to work very closely with existing C code.

Let the rust advocates write their own kernel in rust, there are already some efforts underway to do that. Why screw up an existing freebsd codebase that already works well? What problem does introducing rust into the freebsd kernel actually solve? Apart from a shortage of skilled C programmers?

Or is it just to meet a government mandate to use it? "If you want your stuff in our data centre, you have to show that you've migrating it to rust"; is that the underlying reason? Why is this particular language being pushed so strongly? That's what puzzles me, not the technical push-back, there are good reasons for that. I don't hear the same kind of push for Go, for example.
 
So, once (if!) Rust is introduced into the kernel, will the goal then be to migrate the entire freebsd stack, kernel and userland, to rust?

Going back to 'POSIX.1's friendly post:-

"These young, wild developers will drive you old farts into retirement homes.
You will be disempowered as your code is replaced by languages you hate. Emotions come into play when expertise is lacking.
This type of culture war is also a battle between generations, which will be won by those who can enforce their disruption."

Straight from the horse's mouth. My old second line manager, who told me gleefully back in 1992 that all programmers were obsolete and all code would be machine generated within a couple of years time, couldn't have put it better himself.

I guess having a government mandate to use it means they can "enforce their disruption", as he puts it. So it doesn't have to stand on it's own merits. What a wonderful prospect.

Linus has already bent the knee. They must have made him an offer he can't refuse.
Oh well, I will await developments in freebsd land.
 
Sure, I realise that. I was just arguing the thing out to it's logical conclusion. It's been interesting to see how this has played out in linux, and it will be interesting to see what happens with freebsd.
It will be interesting to see if anyone now makes a counter-argument FOR adding rust into the freebsd kernel.
 
If I understand correctly, Linux introduced Rust for device drivers on 6.15.
Nothing more.

In my humble opinion, layering C -> Rust -> C/asm (from upper layer to lower, near hardware layer in kernels) would possibly OK, but Rust -> C -> Rust would not. Rust -> C would strip out Rust's safekeeping mechanism and cannot inherit to lower layer Rust code.

Anyway, to replace parts of Unix-derived OS'es like FreeBSD, dynamic linking by default should be considered as MANDATORY.

And not sure about the implementation (not dug into implementation of Rust compiler at all), but Rust-specific parts of calling conventions should be "jailed" in dedicated ELF section, with passing ownership to callee on function calls, modified dedicated marker variable to be flipped if the section is actually used, and back to caller on returning to caller.
For outside the dedicated section, the calling conventions SHALL be purely as C.

This would allow determining the callee is in Rust or not by caller and the section should be disposed or not on runtime. As codes in C should NOT know about the section, thus, ignore completely if ELF linker works properly and setup MMU to cope with it.

No need to stick with this specific idea, but something like this kind of functionality would be wanted for languages like Rust (already exists in binding programs?).
 
Freebsd is UNIX. The C programming language IS the unix system programming language, the language the unix kernel is written in. It has stood the test of decades of development and use in production, going back to the late 70s.

What is the rationale for introducing a completely new language into the unix kernel, with all the costs that will incur? What benefits does it add? What problems does it solve?

Just because something can be done, doesn't mean it should be done. The burden of proof lies with the people proposing the new solution, not with the existing system to say 'why not'.
I want to hear what is the case FOR introducing rust into the freebsd kernel, if one exists. And not just "it's going to drive you guys into the retirement homes", that argument carries no validity.

For example, have device drivers written in rust in linux been shown to be demonstrably superior to similar device drivers written in C, to an extent that outweighs the costs incurred by a multi-language programming model? Or have any of the attempts to write operating system kernels in rust been shown to be demonstrably superior to the freebsd kernel?
 
blackbird9 said:
I want to hear what the case FOR introducing rust into the freebsd kernel is, if one exists. And not just "it's going to drive you guys into the retirement homes".
Click to expand...
The only serious example I can think of is to catch up with LinuxKPI for device drivers ported from Linux to 6.15.

I myself don't plan to (at least for now), but if anyone want nova driver for nvidia GPUs (no pre-GSP generations like my Quadro P1000 notebook should be supported, though) to be ported into FreeBSD, Rust in kernel (at least for LinuxKPI) cannot be avoided.

But until nvidia provides proprietary drivers for FreeBSD without Rust sources, I don't think nova driver is needed to be ported. But would be worth than porting (again) nouveau or significantly upgrade (by ourselves) nv.
 
Sure, but that nova article simply says the new driver is written in rust, but not WHY it's written in rust. apart from "because we can, duh". Still, that's an interesting example, it shows some serious work is being done with rust, and presumably the thing works. But they could have written nova in C, just as well, and without adding the difficulty of interfacing rust code to the rest of the kernel.
 
blackbird9 said:
which is going to be a development and maintenance nightmare
Click to expand...
"Don't understand it and it threatens status" They're drivers. They have responsible people.
blackbird9 said:
Is software written in rust really any more secure than good quality C code? I doubt it.
Click to expand...
"That's how Dad did it and it's worked out pretty well so far"
blackbird9 said:
moving target for developers
Click to expand...
C78, C89, C90, C95, C99.... must have been hard for FreeBSD.
 
blackbird9 said:
could have written nova in C
Click to expand...
Here's the answer to this, the other "tradeoff questions", "what are the costs", bla bla bla

The answer is that no, they could not have written nova in C.

They could not write the Apple AGX GPU driver for the M1 in C.

Why? Because the developers didn't want to.

If people don't like that for questions they have no responsibility for answering, that's just... too bad?
 
drhowarddrfine said:
There was no government mandate. It was a suggestion (I guess would be the right word).
Click to expand...
Maybe 'mandate' was the wrong word. Perhaps 'directive'? It looked like it was a pretty serious 'suggestion' from this side of the pond.

cybermaterial.com

White House Pushes Memory-Safe Languages - CyberMaterial

The White House has issued a call to tech companies to transition to memory-safe programming languages, specifically citing Rust, to bolster software security.
cybermaterial.com cybermaterial.com

codesecure.com

White House C++ and C to be Removed from Embedded Systems

"the way coders do their work is of critical importance to national interest" -- white house ONCD
codesecure.com codesecure.com
 
blackbird9 said:
For example, have device drivers written in rust in linux been shown to be demonstrably superior to similar device drivers written in C, to an extent that outweighs the costs incurred by a multi-language programming model?
Click to expand...
That was not the point. Greg KH has stated that Rust was added to the Linux kernel because of memory safety with the idea that devs can avoid an entire category of bugs just using a different language.
 
If I recall correctly, Old Ada is considered as a memory safe language.
So why not fixed target, Ada, rather than a movind target, Rust?
If I understand correctly, Ada is used for "military use-cases", means, several tens of years of stable support if mandatory! Can current Rust assure that?
 
OK, well, let's see how it works out then.... I guess watching linux to see if the number of bugs is reduced dramatically will be one proving ground.
 
I can imagine the in-kernel Rust codes to have a plenty of UNSAFE blocks...
(at worst, almost all of codes to be).

In my humble opinion, UNSAFE shouldn't be used other than defining interfaces to "memory unsafe" languages.

If the codes-to-be-rewritten cannot be written without UNSAFE block other than above-mentioned "defines", the code should NOT be rewritten to mark the code is "mutually memory unsafe even if written in so-called memory safe language".
 
fmc000 said:
That was not the point. Greg KH has stated that Rust was added to the Linux kernel because of memory safety with the idea that devs can avoid an entire category of bugs just using a different language.
Click to expand...
Yes, that it rust's claim, and to my mind that might make sense if you are writing the whole kernel in rust. I think the jury is out though on adding rust code into a large existing codebase written in C or C++ like freebsd, as to how well that will work out, and whether the trade-offs and new types of problems introduced are worth the supposed benefits.
 
You must log in or register to reply here.
Back
Top