3 ms·
From a later email in the thread: > There's a philosophical point to be discussed here which you're skating > right over! Should rust-in-the-linux-ker
by azernik 6y ago
From a later email in the thread:
> There's a philosophical point to be discussed here which you're skating
> right over! Should rust-in-the-linux-kernel provide the same memory
> allocation APIs as the rust-standard-library, or should it provide a Rusty
> API to the standard-linux-memory-allocation APIs?
Yeah, I think that the standard Rust API may simply not be acceptable
inside the kernel, if it has similar behavior to the (completely
broken) C++ "new" operator.
Having done C++-in-the-kernel work, this is precisely right. That work required not only abandoning the C++ memory model, but also implementing a separate standard library that complied to kernel-space limitations/requirements.
- dralley 6y agoYou're skipping over all the emails that explain that it's not a fundamental limitation, many of the falliable allocation APIs already exist and many others have been in planning for a long time.
- azernik 6y agoI was referring to the C++ description as "precisely right". Though note from those emails that Rust-in-the-kernel will also require a rework of a lot of stdlib stuff, especially if they want to use the kernel allocator; it'll just be a LOT neater and more idiomatically-Rusty than the stuff I had to deal with, and will be much more compatible with off-the-shelf Rust libraries. And the developers of this Rust port repeatedly talk about removing panicking API calls from the library for kernel use, and adding extra non-panicking versions to the standard library. It's only that latter work that will likely make it into Rust upstream.
- ncmncm 6y agoYou can write bad code in any language. You can invent BS about any language. Linux kernel does not use glibc, why assume it would use the default generic application-level std lib for Rust, or for C++? FUD does not enlighten.