Rust in the FreeBSD kernel

My take so far:

Linux is much further along than this project. Namely, this project doesn't interface to many kernel APIs. From my observation the big discussions in Linux come from implementing the foreign function bindings for complex APIs. Not only does that take a lot of time and code, now the C developers that want to modify such an API are forced to also change the FFI for Rust accordingly and at the same time. Thus they have to know Rust, and FFI is not the easiest part of Rust.
 
Just in my time :'‑(.
When I thought that I had moved out of these "new cooler ideas" for the OS, this and other news, like Wayland, started to get traction in the FreeBSD community.
 
cracauer@ said:
My take so far:

Linux is much further along than this project. Namely, this project doesn't interface to many kernel APIs. From my observation the big discussions in Linux come from implementing the foreign function bindings for complex APIs. Not only does that take a lot of time and code, now the C developers that want to modify such an API are forced to also change the FFI for Rust accordingly and at the same time. Thus they have to know Rust, and FFI is not the easiest part of Rust.
Click to expand...
This is the same problem DMD D had and why it was removed from ports when upstream failed to implement 64-bit inodes. They couldn't implement the ifuncs needed to allow both old and new support.
 
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.

Clearly, introducing nova driver for nvidia GPUs with GSP in them requires Rust binding. But, older GPUs without GSP (GPU System Processor) are supported only by current proprietary drivers, thus, no worries for now.
 
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.
 
I guess what he's done is a proof-of-concept. Presumably FreeBSD's problem is that a lot of drivers are picked up from linux and ported. So if the linux code gets written in rust, freebsd is pretty much forced to follow. Unless freebsd starts developing their own drivers. How hard can it be?

I wonder if there is a rust to C translator. Still, I'm sure that approach would have problems too, working with generated code is never much fun, and the programming models of the two languages are quite different.

I'm not a freebsd developer, but I agree with Cracauers initial comments. If the freebsd project accepts rust in the kernel, now you've got to know two (completely) different languages to work on the kernel, or the parts of the kernel you can work on are limited; and there are bound to be all kinds of problems at the interface between code written in the two languages, which will make debugging more difficult. Once rust gets embedded in the kernel, there will be no way back. Perhaps the best freebsd can do is to try to ringfence it. Or best of all, reject it outright.
 
POSIX.1 said:
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.
Click to expand...
Let the rust jerks go and write their own operating system then, instead of trying to get a free ride on the back of freebsd's success, which they never contributed to.
And remember: your turn will come, sunshine, nothing is more certain. Some other obnoxious twat will be calling you an "old fart" too, soon enough.
 
Beastie7 said:
Depending on Linux for this stuff won’t be viable or economical for FreeBSD long term. Also, DRM sucks and its terribly outdated.
Click to expand...
Unfortunately, no.

It would simply cause lack of drivers for new hardwares, unless hardware manufacturers are mandated to disclose ALL information about their hardware that are needed to write device drivers, free of charge and with permissive licenses like BSD 3 or 2 clause.

Or hardware manufactures provides (regardless open source or proprietary) device drivers for FreeBSD like nvidia does currently. On nvidia GPUs, same GPUs running on Linux runs on FreeBSD, too, on X11 and Wayland.

Another possibility (and would be best for all non-Windows nor non-macOS OS'es) would be making UEFI to be complete VM host and all devices to be mandated to use UEFI runtime services, which are well abstracted.
 
cracauer@ said:
Just to clarify, a Google Summer of Code project means very little to the direction of the project.
Click to expand...

It is going to be pretty interesting if the Rust experiment works out for an operating system.

By that I don't mean running Rust in kernel, that is easy. We also had effort to bring C++ to certain kernels, and when it was done, the said kernels did not get rewritten to C++, they merely got the capability.

The experiment is bringing the completely new generation of people that have different routine to something that is established long ago and still in operation. Yes operation is slowing down because young people aren't into low levels and C and classic language ecosystems, they want modern features, package manager, isolated standard lib, etc. In essence they would like to use a system-decoupled language as a system langauge. Which is certainly possible, but it is in a heavy dogma clash with old Unix/C church. In order to bring them in, some concessions will be made.

So what happens in the future, when parts of FreeBSD kernel are rewritten to Rust, let's say when it gets to 50% ? We now have 50% of the codebase Rust and possible majority of core people Rust developers. How are we going to reconcile that the upcoming defacto language is not married to Unix?

Never mind that opening system development to the masses via Rust is just going to introduce another class of troubles. The masses cannot program operating systems, it is a specific thing. In my opinion expectation that standard Rust programmer is going to hop into the kernel just because its Rust, is completely flawed. A junior programmer is not going to be good by the virtue of language he uses. Seniors on the other hand do not have issues with technologies and tend to be polyvalent. Anyhow, if the language design does not allow memory unsafety outside of critically marked code, it certainly still allows a plethora of synchronization issues.
 
blackbird9 said:
I guess what he's done is a proof-of-concept. Presumably FreeBSD's problem is that a lot of drivers are picked up from linux and ported.
Click to expand...

No, very few drivers are picked up because almost all drivers in Linux are GPLed. DRM and wifi are special because they have been contributed by vendors and are not GPLed.

So if the linux code gets written in rust, freebsd is pretty much forced to follow. Unless freebsd starts developing their own drivers. How hard can it be?
Click to expand...

Very. Even with example driver code to read things like DRM and Wifi are very hard to write drivers for without hardware documentation, That's why they are currently imported when the license allows it.
 
cracauer@ said:
Very. Even with example driver code to read things like DRM and Wifi are very hard to write drivers for without hardware documentation, That's why they are currently imported when the license allows it.
Click to expand...
This is correct, and I wonder - what can a "safe" language do about that? When adding anything to the list of kernel implementation languages, you create churn, waste, problems. Will removing,say, memory errors, be enough of a benefit to do that when it does little to the problem of missing (and accurate) documentation? How long will you have to carry the extra load untill it starts to pay off?

We would be better served with a way to have user mode drivers and encapsulate all that to user space, I think. But I won't worry too much about the kernel devs to welcome rust with open arms into kernel space.
 
If any new language are going to be in kernel to replace some parts, it should be completely "a dropin replacement" object files.
Otherwise, replacement introduce unacceptably strong pain.
The code SHALL be sanely linked against existing, not yet rewritten parts and sanely run.

This should be bare minimum requirement. And in case of Rust, it almost fatally hurts the philosophy of Rust (even though possible with CDYLIB).
 
You must log in or register to reply here.
Back
Top