Rust in the FreeBSD kernel

blackbird9 said:
True, but I always think of C and asm as closely related cousins. Whereas a "safe" language like rust is a rather different, higher level paradigm. But yes, strictly it would be 3 languages.
Click to expand...
Regardless it's Rust or another, memory-safe languages should be used for mutually memory safe parts, and let mutually memory-unsafe (i.e., not sure such devices exist or not, driver for hardware which shares input and output buffer physically) parts left with C and/or asm, to indicate the part is memory safe or not with what language is used.
 
Andriy said:
I am following the Linux Rust experiment with much interest.
The most curious thing for me is where and how they will harness the (comparative to C) great power of Rust.
But so far I see only simple and trivial kernel drivers being done in Rust.
Click to expand...

Yes, Rust would play its advantages much more in complex algorithms, not bit fiddling with devices.

But all the complex code in a kernel requires lots of access to existing data structures. Which implies a need for lots of interface code. And which wouldn't be entirely safe because you constantly access C memory.
 
cracauer@ said:
Aren't device drivers inherently not suitable for safe programming? Every time you write into device memory it is unsafe.
Click to expand...
I think so, too, but if the hardware is almost paranoid with memory safety (divide input and output buffer and independent flag regs to require something to device and to require something from device to driver, and so on), driver possibly can be memory safe. Maybe rare, though.

Not sure how nova driver is (going to be) implemented.
 
cracauer@ said:
Aren't device drivers inherently not suitable for safe programming? Every time you write into device memory it is unsafe.
Click to expand...
Yes. And now they want to burden those who do this on a daily basis with keeping the ffi up to date? Let's see how long it takes to turn into a fui, and the burden to keep it up is placed on the rust people. Then a stunt or two from the crowd that brought us the no-foreign-file-systems hassle and I will not take any bets on how much longer that will be allowed to continue by the powers that be.

Also, does rust et all have a way to stop the compiler from reordering or performing some magic on memory writes? Combining memory writes into one will create interesting results.
 
Crivens said:
Also, does rust et all have a way to stop the compiler from reordering or performing some magic on memory writes? Combining memory writes into one will create interesting results.
Click to expand...

To the best of my knowledge no compiler does that automatically. In C and C++ you can do it by hand. It gets complex if you consider container classes such as C++ vectors. Vectors are guaranteed to be linear in memory, so just tiling a memset over one would work.

In the case of Rust there might be mandatory array bounds checks on top of individual word writes. I don't know how many array bounds checks the Rust compiler or the LLVM backend eliminate in a tight loop.

Generally I have not seen the promises of very smart compilers work out in the last decades.
 
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...
I heard they bring their parents to job interviews so... no, I don't think so.
 
POSIX.1 said:
These young, wild developers will drive you old farts into retirement homes.
Click to expand...
Remember that C and C++ didn't come from the current "old fart" generation of developers. It came from those long since retired. So there is no reason to believe that once the younger generation even learn to write their own languages and operating systems, they will do better to change the status quo.

Best thing to do if someone wants to make it their profession and be employed is shut up, conform and do what the seniors are doing. Sure, improve things but don't be a heretic.
 
cracauer@ said:
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.
Click to expand...
That's not my understanding, but rather that if someone wants to change the FFI, they need to coordinate with the consumers, which would be the maintainers of the Rust drivers. This put the adoption of the FFI by Rust drivers on Rust maintainers, solving this problem. The last big dustup seemed to be about not even wanting to specify a FFI in order to de-facto keep out a Rust consumer.
 
Andriy said:
I am following the Linux Rust experiment with much interest.
The most curious thing for me is where and how they will harness the (comparative to C) great power of Rust.
But so far I see only simple and trivial kernel drivers being done in Rust.
Click to expand...

In what features is this great power of Rust? Genuinely curious.
 
cracauer@ said:
Aren't device drivers inherently not suitable for safe programming? Every time you write into device memory it is unsafe.
Click to expand...

That's the half of job of driver, the kernel side can be safe, like managing buffers and such.
These so called memory safe languages promote separation of unsafe pieces from the rest of the codebase, so it can be given greater attention.
 
Zare said:
These so called memory safe languages promote separation of unsafe pieces from the rest of the codebase, so it can be given greater attention.
Click to expand...
This would be best achieved by separation of used language with whether or not the part can be memory safe or not. Keeping mutually memory unsafe parts in C and/or asm, other to some memory safe languge, in source file level.

This way, any part written in memory safe language states that "not at all needed to look into on memory safety related bugs", and others states "needed to be aware if memory safety bugs are suspected".
If this is impossible, why memory safe languages needed to be introduced?
I.e., if *.rs is assured not at all needed to look into on memory safety related bugs, it would be worth considering Rust. If not, why consider Rust?
 
cracauer@ said:
To the best of my knowledge no compiler does that automatically. In C and C++ you can do it by hand. It gets complex if you consider container classes such as C++ vectors. Vectors are guaranteed to be linear in memory, so just tiling a memset over one would work.
Click to expand...
Oh, you would be surprised what can happen. Consider this:
Code: 
dma->src = source;
dma->dst = dest;
dma->size = len;
Now, these registers are right next to each other in the address space. The compiler could figure out that invoking the load store unit 3 times is costly, so it might combine writes. Or reorder them.
Code: 
move.l   d0,(a0)+
move.l   a3,(a0)+
move.l   a2,(a0)+
You see where this is going?
Code: 
rlwimi r3,r4,32,32,0    // can't remember the syntax now, but this should shift r4 up 32 bit and place the 32 bits in it's lower part into the upper 32 in r3
stll      r3,xx(r5)          // write dest and len in one instruction

C/C++ compilers more or less treat memory as a volatile object, untill they can prove that this is not the case. What about rust?
And this gets even better when you realize that the code you feed into the CPU is not the code running because it is translated into micro ops and all the nice things can happen there as well, like removing stores from the pipeline if the next instruction writes to the same address. Your program won't notice, but the hardware will. Having these high level languages do the same as f.e. assembly is like using seven mile boots, it might hurt really bad when doing it wrong.
 
msplsh said:
Once the memory crosses the FFI border, Rust will make sure Rust code doesn't screw it up.
Click to expand...
Unfortunately Rust can't protect the data from being stripped out under it.

Same with the difficulty of using C (or traditional C++) middleware with smart pointers. Unless Rust "owns" the memory, it can still only make (educated) guesses at its validity.

I.e imagine Rust has some Texture object but the OpenGL context gets wiped when the app gets paused (a very common process with Android). Rust will need to track the onResume event and reinitialize all of its textures. Without this manual work, Rust is effectively holding a bunch of dangling pointers. Yes, this OpenGL/Android design is shite but the computing platform is full of this kind of stuff.

(This is why Redox OS is very interesting (lifetime tracking from the lowest layers) whereas spamming Rust ontop of C in Linux or FreeBSD is less so).
 
kpedersen said:
Unfortunately Rust can't protect the data from being stripped out under it.
Click to expand...
That's either not the driver writer's bug (and also would happen to any other language, so what's your point?) or an additional contract that the driver writer has to attend to (which also would happen to any other language).
 
msplsh said:
That's either not the driver writer's bug (and also would happen to any other language, so what's your point?) or an additional contract that the driver writer has to attend to (which also would happen to any other language).
Click to expand...
Yes and no. Do you have the constructs in a language to stop the code from using these pointers behind your back while you still figure out if they are valid?
 
You must log in or register to reply here.
Back
Top