Hacker News Reader

Comment by kibwen | Hacker News Reader

Not a kernel hacker, but if it's just for fun, I don't know if you'd need to limit yourself to no_std crates. Allocation is supported (if it wasn't, then Rust's stdlib wouldn't be adding fallible allocation APIs to support the kernel usecase (and even if crates in the wild aren't using these APIs and abort on OOM, again, this is just for fun)). Meanwhile, I feel like OS-specific stuff performed by libstd (e.g. threads, networking) must surely be supportable somehow, since the OS is right there and all its facilities still exist, even if you might need to adjust codegen to account for the difference between kernelspace and userspace (I assume you would need to compile against a specific target?).

View on HN

Although Rust for Linux has its own alloc, that isn't really alloc. It is like if you wanted Coke and got Pepsi, if you just wanted fizzy brown beverage you're fine, but if you actually cared this isn't OK.

Rust's String (the mutable owned string type from alloc) implements AddAssign meaning you can write fname += ".txt" and that works, but Rust for Linux doesn't allow that. This is just a really obvious example, there are many other differences

You can't use methods that may panic on OOM like Vec::push or Box::new. This means that close to 100% of crates that use the stdlib won't be usable in the kernel without modifications.

My understanding isn't that you _can't_, but that you _aren't allowed to_ by kernel policy. (The risk being that the kernel will panic on OOM, which is not an acceptable way for the kernel to deal with OOM conditions.)

If this is out of tree, AFAIK you can use these all you want. Whether or not you _should_ is obviously a different matter.

No, you can't - they don't exist in Rust for Linux.

In Rust the alloc library's Vec has a function Vec::push(&mut self, value: T)

https://doc.rust-lang.org/std/vec/struct.Vec.html#method.pus...

In Rust for Linux their custom alloc library does not have that function offering instead Vec::try_push(&mut self, value: T) -> Result<(), TryReserveError>

https://rust-for-linux.github.io/docs/alloc/vec/struct.Vec.h...

What’s up with the Allocator API? Then it could be Vec::push<Allocator>(..), giving it an always-failing one for example.

Vec::push<Allocator>(..) makes no sense, the Allocator is a parameter to the Vec type.

That’s what I meant to write

OK and... ? What purpose does an always-failing allocator for Vec have? I guess maybe it's useful for some unit testing cases, but otherwise it seems pointless.

Reply on news.ycombinator.com