Hacker News Reader

Comment by karmakaze | Hacker News Reader

Anyone thinking that Rust is ready to be used in the kernel, just read the post first. It is very short. Then read these comments to look for what you need answered.

For me, the main point is Can Rust be written to guarantee that no oom (or other hard fail 128-bit math) panic occurs that is not under control of the written code? I want the answer to be yes and also want to see how (which isn't far off from what Linus is asking).

View on HN

> Can Rust be written to guarantee that no oom

Yes, easily, OOM is entirely a library created concept in rust, just don't use the standard library (or the `alloc` susbset of the standard library) and you don't have OOMs...

> (or other hard fail 128-bit math)

128 bit math, and floats, need to be avoided by just "not using them", the same as for floats in C code in the kernel...

What's the issues with floats? Everyone is casually talking about this issue like it's common knowledge. Online searches of floating point panics doesn't really bring up any information beside bug reports.

Is it something about floating point operations not actually being fixed-sized?

I would like to know about this too. Did you find any interesting article?

In a modern pre-emptive multitasking operating system, the kernel needs to be able to stop what your user task was doing, do its own thing for a while or even run a different task entirely - and then put everything back apparently as it was and allow your task to carry on. The CPU affords this capability by providing a way to bottle up all its internal state, store that somewhere, and then put it back later.

Operating system kernels don't generally need floating point math (some of them use it anyway, lots don't).

So if your CPU has a way to say "Bottle your state, but er, don't worry about the floating point stuff" and it's faster, or uses less memory, or both, which are common, all the kernels (like Linux) which do not use floating point know they aren't touching that anyway and needn't bottle it up. This is potentially an important performance win.

If you try to take this performance win, but then you actually do use floating point in the kernel, the world suddenly changes beneath the feet of user tasks. A program is adding up some floating point numbers, and then, huh, suddenly the total is now negative? Wait, now it's zero? Nope, negative again? What's happening! If the program was aware of being interrupted this makes sense, but the whole point of pre-emptive multi-tasking is not to need to custom design every program to be interrupted everywhere.

So Linux (mostly) never uses floating point.

To say what tialaramex said in a different way, the OS needs to save all the user space registers to the stack when it interrupts a task, so it can do it's own thing. Floats are held in separate registers, so as an optimization it can skip saving those registers to the stack and just not use them (as long as it doesn't call any code that might use floats, and returns back to the same task afterwards). This turns out to be a substantial performance improvement, because there are lots of small syscalls that return quickly.

128 bit integers not working is a bit dumber, the compiler relies on some functions being implemented for them to work, and for whatever reason the people behind rust in linux just haven't implemented those functions (yet?). They use the normal (non floating point) registers though, so there is nothing stopping them from being implemented. https://github.com/Rust-for-Linux/linux/issues/11#issuecomme...

You got two good answers, but also, there's also now some pressure to make these scenarios better (say, "compile error if you use a i128" rather than "just don't use an i128"), which is nice. I'll be glad on the kernel's needs putting some pressure on Rust to improve.

Yes, don't use the std lib (or more specifically the alloc crate) and don't use types like floats and u128.

Is it possible to use Box (which is special cased in many places in the language and thus cannot be replaced, unlike for example Arc) without the alloc crate?

a replacement to `alloc` would define a `Box` structure and tag it as `#[lang = "box"]` but not define any crashy APIs. this would accomplish the goal, but is an annoying patch that `alloc` should work to obviate upstream

Reply on news.ycombinator.com