Rust in the FreeBSD kernel

msplsh said:
"Don't understand it and it threatens status" They're drivers. They have responsible people.
Click to expand...
Bindings / abstractions are a very well understood issue since the 70s. It does indeed threaten a project by drowning it in technical debt. Since Linux started with Rust a couple of years ago, they are *still* writing the bindings layers. This should be raising some serious red flags.

This kind of reasoning is like the classic one I see, assuming a developer "doesn't own an iPhone because they are poor". When really it is often because they see issues with the platform that regular users don't.

msplsh said:
"That's how Dad did it and it's worked out pretty well so far"
Click to expand...

Dad? Try granddad. The computing industry was developed long ago with a reliance on C. Dad simply inherited it and then us and then the newer generation. If Dad couldn't switch systems language, and we couldn't switch systems language, why do you think the next maintainers in the line can?

msplsh said:
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.
Click to expand...

Didn't want to != Could not

I do get the sentiment though. C is tried, tested and a bit boring. If you are going to commit to a feat of engineering like a GPU driver, adding a trendy new language is a good incentive, making it all exciting again. Open-source is all about playing around and having fun.

msplsh said:
C78, C89, C90, C95, C99.... must have been hard for FreeBSD.
Click to expand...
C really isn't renowned for being a moving target like Rust is. And the fact that we are still on C99/C11 (and not even thinking about C23) is good evidence that it *is* hard for a large project like Linux and FreeBSD to chase language versions.
 
"If you are going to commit to a feat of engineering like a GPU driver, adding a trendy new language is a good incentive, making it all exciting again. Open-source is all about playing around and having fun."

Yes, that's one I thoroughly approve of. As long as you're there to fix the bugs later on 😁
 
blackbird9 said:
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?
Click to expand...

Well, C is a very light language that misses many abstractions, including zero-cost abstractions that languages like Rust and modern C++ have. Just as an example, the C library has a quicksort and a binary search, but neither are type-safe, they rely on casts everywhere. Hash tables in Linux and FreeBSD are implemented with interesting macros instead of as proper reusable code.

That's apart from the memory safety.

(Saying this doesn't mean I want Rust in the FreeBSD kernel. It is answering the question why people want higher level languages as long as it doesn't kill performance, which C++ and Rust offer)
 
kpedersen said:
they are *still* writing the bindings layers
Click to expand...
Who cares? They wrote them to begin with?
kpedersen said:
If Dad couldn't switch systems language, and we couldn't switch systems language, why do you think the next maintainers in the line can?
Click to expand...
Lack of imagination. It's all "lol look at those Redox chuckleheads" until it works, I guess.
kpedersen said:
Didn't want to != Could not
Click to expand...
You can't make people do stuff for free. The alternative is that the driver just might not exist.
 
drhowarddrfine said:
As the title of the article says, "urges" is the word but they can urge all they want and we can still use whatever we feel like.
Click to expand...

I have not seen that white house advice being taken seriously, not even in government agencies. These agencies would propably have the hardest time switching languages or having mixed-language systems.

But Musk's boys can re-write the social security system in 3 months, right?
 
cracauer@ said:
I have not seen that white house advice being taken seriously, not even in government agencies.
Click to expand...
It conflicts with a few coding standards (i.e some modules in DO-178C). These will take decades to change for one.

UK specific, DEF STAN 00-55 (or 00-56?) it is recommended to have multiple "independent" and "diverse" vendor toolchains to avoid systematic errors. It is likely Ferrocene will be the only safety critical Rust toolchain for a long time. I did hear a rumor that Greenhills might curate its own Rust release. But due to upstream, I don't believe that will class as a different vendor anyway.

Quickly flicking through defense related jobs in the UK, I do see some Rust. A very rough breakdown (for UK) is:
  • ~5% Rust
  • ~20% Ada / SPARK
  • ~40% .NET/Java
  • ~30% C++
Ada is almost always as a "nice addition" alongside other languages. Its useful for legacy maintenance, most places tend to be phasing it out.

Though, admittedly we also put Rust (and C++17) on our juniors recruitment ads too even though we have no Rust projects (and use C++11). It attracts young candidates who don't really have much experience with any language yet and just chose Rust or "modern" C++ because of the hype or because they are worried about competing with "seniors" who have been using C++ for decades. I suspect that most companies are doing this, contributing to the higher than expected 5%.

Edit: NATO STANAG procurement contracts may enforce different toolchains for verification purposes. I have not run into this myself but have something equally as bizarre when it comes to a toolchain requirement for a defense contract that (luckily for you) I mustn't rant about here.
 
kpedersen said:
chose Rust because of the hype or because they are worried about competing with "seniors" who have been using C++ for decades
Click to expand...
This is the lack of imagination I'm talking about. The idea that nobody who has been using C++ thinks there's anything special about Rust. I've got Bjarne's Special Edition book here I bought brand new.
 
msplsh said:
This is the lack of imagination I'm talking about. The idea that nobody who has been using C++ thinks there's anything special about Rust. I've got Bjarne's Special Edition book here I bought brand new.
Click to expand...
Its more that the "special" aspects of it, are greatly undermined by the disadvantages of it. Practicality and pragmatism is way more critical than imagination.

C++ developers in particular are already quite familiar with Rust's RAII mechanisms so don't see it as breathtakingly different or special compared to how a Python or .NET developer might. So really that only leaves the compile time borrow checker which tends to fall off as soon as you deal with boxed / heap types dynamically allocated (which so much is). Then you are often back to good ol' reference counting. Not so exciting.

But integrate a tiny C front-end in there so Rust can directly consume native middleware in the same way that C++ can. Now that would suddenly make it more interesting.
 
kpedersen said:
greatly undermined by the disadvantages of it. Practicality and pragmatism is way more critical than imagination.
Click to expand...
That's just like, your opinion, man.

I only see people complain about "updating bindings" and "who will maintain stuff" as if those problems aren't currently being solved.
 
cracauer@ said:
I have not seen that white house advice being taken seriously, not even in government agencies. These agencies would propably have the hardest time switching languages or having mixed-language systems.

But Musk's boys can re-write the social security system in 3 months, right?
Click to expand...
I thought it was 3 weeks? Elon brought the date forward...😁
 
msplsh said:
That's just like, your opinion, man.

I only see people complain about "updating bindings" and "who will maintain stuff" as if those problems aren't currently being solved.
Click to expand...
Indeed. If they do solve them, then people will update their criticisms of Rust (or likely its successor language). So far I can see them solved in two ways:

1) Bolt on a tiny C frontend (a little bit like cgo but with full interop).
2) Rust all the way from the bottom up (i.e Redox OS). Then less need to even bind against C.

What doesn't work is bindings package managers like npm/cpan/crates/pip. This is not resilient enough for systems development. Unfortunately I suspect that the Rust community is dwelling here instead of solving the problem.
 
msplsh said:
"what if it's all a big hoax and we create a better world for nothing"
Click to expand...
Yeah, it's so unfair!! Well, imagine you're running a data centre. You've got 10000 instances of freebsd with nvidia AI co-processors and you want that nova driver to put AI workloads onto the hardware you just spent tens of millions buying. That new driver written in rust had better be stable. 😁

BTW... I'd be prepared to bet those boys writing nova aren't working for free.... I'm sure nvidia has thrown some gold their way...
 
kpedersen said:
Quickly flicking through defense related jobs in the UK, I do see some Rust. A very rough breakdown (for UK) is:
  • ~5% Rust
  • ~20% Ada / SPARK
  • ~40% .NET/Java
  • ~30% C++
Click to expand...
I had a quick look at indeed.co.uk last night. I only found one job specifically asking for rust, and one more that mentioned they wanted people who knew "languages like rust and go". I think the adoption in the US must be quite a lot wider than over here.
 
T-Aoki said:
Another unfortunate fact (for non Rust lovers) would be Linux kernel introduced support for Rust on kernel 6.15.
So upgrading LinuxKPI to 6.15 (currently graphics/drm-latest-kmod is at 6.9) in the future for supporting new drivers could likely cause FreeBSD kernel to have Rust bindings, at least for LinuxKPI.
Click to expand...

T-Aoki said:
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.
Click to expand...

I like how people just casually glanced over these comments. This is a potential serious issue that will need to be addressed at some point. How are we going to deal with this? Also, has anyone even assessed whether GPU vendors even want to work with Rust for their hardware? I recall a time where industry standards were rejected (ie EGLStreams vs GBM) due to evangelical nonsense with Linux kernel developers. I'm noticing a similar circumstance with Rust. More unnecessary nonsense being shoved down our throats.

If our access to architecture details is limited for us to have GPU driver sovereignty; then perhaps there should be some sort of special interests group to share knowledge with GPU vendors on driver development. If the project can deliver a better alternative to DRM (in C/C++, maybe leverage KGI?), that'll give vendors an exceptional baseline to collaborate with. Otherwise Rust will eventually decay itself into parts of the kernel. IMO. That I do not want.
 
kpedersen said:
C really isn't renowned for being a moving target like Rust is. And the fact that we are still on C99/C11 (and not even thinking about C23) is good evidence that it *is* hard for a large project like Linux and FreeBSD to chase language versions.
Click to expand...
I would have thought that the very last thing you need in an operating system kernel is to write it in an unstable language. You need a solid foundation.
 
blackbird9 said:
thecodinglove.com

Elon Musk targets COBOL in a rewrite no one actually asked for

Elon Musk wants to replace the decades-old COBOL systems powering U.S. Social Security—with Java, probably, and in just a few months.
thecodinglove.com thecodinglove.com
Tens of millions of lines of cobol, developed over decades of work. What could possibly go wrong? 😂
They wrote a GUI for a car... now they think they can do real work... 😁
Click to expand...
They did that in python iirc.

And the legal eagle (tweed stuffed lawyer !!) did a vid telling them that the 120year olds are due to some RFC that deals with unknown birthdays.
 
I can say with confidence that they won't even complete their analysis of how the old system works in 3 months... :)

In fact the date of that article was 7th April, so Elon's announcement was just around that time. Sounds to me like time's up already. Where's the new system? He's missed the date!
I think he gets an F grade for this one. F for fail 😁 . Sorry Elon, if you're reading; the rockets were good, at least.
 
blackbird9 said:
I can say with confidence that they won't even complete their analysis of how the old system works in 3 months... :)
Click to expand...
You mean, after firing all those with a clue? Those should immediately form a new company and rent out engineering consultants with a "market oriented and fair" rate. You know, the kind that would make McKinney blush? That would be karma.
 
msplsh said:
Missed one: Just update the bindings with the maintainers who are maintaining things.
Click to expand...
Unfortunately not. As mentioned earlier, the issue with language bindings leading to considerable technical debt is already well explored (a very verbose paper but actually covers the issue well, including multiple different approaches to bindings).

You can't force the maintainers to work on them. So in time, this means you are then stuck maintaining them yourself. History has shown that bindings have a tendency to rot. Particularly due to the fact that they need to provide full coverage rather than use one or two functions. This makes them especially fragile to API breakage.
 
You must log in or register to reply here.
Back
Top