Ushering out strlcpy()

Posted Aug 30, 2022 14:11 UTC (Tue) by andy_shev (subscriber, #75870)
In reply to: Ushering out strlcpy() by NYKevin
Parent article: Ushering out strlcpy()

Good explanation why Rust sucks... No, thanks, we do not need page faults and sleeping context in the critical sections in the kernel.

Ushering out strlcpy()

Posted Aug 30, 2022 15:26 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

I don't see the connection. The general purpose `std::string::String` might not work in all contexts, but there is a *lot* of code that doesn't work in such contexts anyways. The kernel is certainly free to make its own String which can be used from interrupts and such (with appropriate error handling of course); there's nothing magic about String in Rust and is "just" library code.

Ushering out strlcpy()

Posted Aug 30, 2022 17:33 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

The kernel does have its own String:

https://rust-for-linux.github.io/docs/alloc/string/struct.String.html

Here's the equivalent Rust standard String (well, alloc::string::String, userspace Rust programmers would use it from std but it's equivalent)

https://doc.rust-lang.org/alloc/string/struct.String.html

You'll notice that the standard String has a lot of stuff that the kernel doesn't. And the kernel only has try_reserve() so you can't just go around reserve()ing memory which might not exist as userspace programmers often do.

The kernel has (or will eventually get) all of core, the Rust library where core language features that are not just inside the compiler live, so that's stuff like an Option type, a Result type, most of the methods you think about for built-in types. But it doesn't have std, the library where OS depending features like File I/O and Networking live, and it has its own rather different alloc, a library where the allocator and related features (such as a growable String) live.

Ushering out strlcpy()

Posted Aug 30, 2022 15:43 UTC (Tue) by excors (subscriber, #95769) [Link]

The Rust standard library isn't fully suitable for use in a kernel (or many other embedded environments), but that's okay, you can find or implement your own equivalent types that meet your requirements (just like you'd have to when using C). E.g. there's heapless::String (https://docs.rs/heapless/latest/heapless/struct.String.html) as a fixed-capacity string without dynamic allocation, where functions that might exceed the string's capacity (like String::push) return a Result<> so it's always safe and the caller has to explicitly decide how to handle that case.