The Case for Rust (in the base system)

For /usr/src/contrib:
Packages contributed by 3rd parties.

For /usr/src/sys/contrib:
3rd-party imported software such as OpenZFS.

See Source Roadmap section of /usr/src and /usr/src/sys pages on github mirror linked, both near the bottom of the each pages.
 
Azrael said:
I'd rather show something everyone could see and examine. Go to FreeBSD's github for the kernel source here. Half way down on the right you'll see a breakdown of all the languages used like this:
Click to expand...
There is c++ code in some user land programs and tools. None in the kernel. You must be a refugee from the land of Linux :) https://github.com/torvalds/linux contains only kernel sources while https://github.com/freebsd/freebsd-src contains much more than the kernel.
 
Even if using copy-by-value, it would be possible to allocate properly configured dedicated memory block outside stack and pass its address and size only via stack, at the cost of allocation/deallocation on each function calls.
Don't know how Rust can do so or not, but if pop instruction doesn't assuring that memory used for popped values (before stack pointer) is zeroed, using dedicated one-time region and clear after return seems much more memory-safer.
 
You would think that LLVM's post-frontend optimizations would compute out many of the moves in static enough code. And those optimizations run the same for C++ and Rust.
 
cracauer@ said:
You would think that LLVM's post-frontend optimizations would compute out many of the moves in static enough code. And those optimizations run the same for C++ and Rust.
Click to expand...
You would, but it would not have success. These are copy instructions that transport values from foo(x) to bar(x) to fluff(x). The only way to pass values down a call chain is by using a copy, and since bar or fluff have no idea where they get called from, they need to copy things down. And you need to copy things or you can not be sure that someone doesn't get a pointer to the original data and changes it. Me old dad had barrels of fun with this in fortran, when someone assigned a new value to a parameter that happened to be PI. The only way to be safe is to call by value, not reference.
 
Crivens said:
You would, but it would not have success. These are copy instructions that transport values from foo(x) to bar(x) to fluff(x). The only way to pass values down a call chain is by using a copy, and since bar or fluff have no idea where they get called from, they need to copy things down. And you need to copy things or you can not be sure that someone doesn't get a pointer to the original data and changes it. Me old dad had barrels of fun with this in fortran, when someone assigned a new value to a parameter that happened to be PI. The only way to be safe is to call by value, not reference.
Click to expand...

So this is all about function calls?
 
cracauer@ said:
So this is all about function calls?
Click to expand...
Looks like it. You have to isolate the environment between calls, so there is no backblast from bad actors/calls/... down the chain. How else do you want to do this, without a very fine grained MMU? And that would be such fun to program, bug free...

In the end, there is a price to pay for isolation. Be it with MMUs and the TLBs, table walks, ... or here with call-by-value.
 
OK, I misunderstood the linked article then. I thought it was about computation using stack-allocated variables.
 
That would indeed be something llvm should eliminate equally good for all languages.
 
sidetone said:
https://www.phoronix.com/news/Redox-OS-Porting-Plans "The Current State & Plans For Porting Linux/BSD Software To Redox OS"

This one is quite the opposite.
Click to expand...
From Phoronix comment #4
We still have a relatively slow kernel since not much time has been spent on optimizing it." Here's link to the microkernel system design portion of their documentation: https://doc.redox-os.org/book/ch04-01-microkernels.html

This has always surprised me, as solving the context switching overhead problem must be the very first thing a viable microkernel architecture overcomes. And yet it seems that Redox OS has always worked on everything but that, building code for years on top of a microkernel that has not yet solved the critical fundamental problem that doomed all others.
Click to expand...

ArcaOS (the "new" OS/2) has acknowledged users want Wi-Fi adapters to work, but they have prioritized UEFI over Wi-Fi saying, "If your server doesn't boot, then nothing else matters."

Apparently, Redox has flipped that backwards: "If your server is slow, everything else matters before fixing that."
 
devclass.com

Rust developers fear language is getting too complex and prefer bug fixes to new features • DEVCLASS

A new State of Rust survey shows that developers would prefer to see compiler bugs fixed and performance […]
devclass.com devclass.com

"A new State of Rust survey shows that developers would prefer to see compiler bugs fixed and performance improved rather than new language features added, however, their biggest fear is excessive language complexity."

Excessive language complexity? Oh dear. Second-system syndrome?

Maybe it doesn't matter, you won't need to worry your head about it; you'll only need to know how to ask the AI to write some code for you which you will cut and paste in. Maybe they can get the AI to ask the code generation questions eventually as well and replace the primate at the keyboard completely. The boss is going to love it.

In passing, it's remarkable how "disk space usage" and "memory usage" are the least important concerns. Times have changed. I can get a 4-core PC with 16GB RAM and 1/2 terabyte of SSD storage for just over $100 on aliexpress... I guess that's "entry level" spec now.

1708874829181.png
 
Interesting that compiler bugs feature so high in the annoyance list.

Is the current compiler bug situation really that bad?
 
bakul said:
Thus (indirectly) contributing to the bloat we all complain about.
Click to expand...
There probably needs to be some rule for software, equivalent to Moore's law for hardware, that states something like "software expands to fill the available hardware capacity". Although I seem to remember 640k was going to be enough for anyone...
 
 
You must log in or register to reply here.
Back
Top