3 ms·

I don't think you can use "double standard" as a derogatory term when you're comparing the needs of kernelspace code and userspace code. ...plus, they're alrea

I don't think you can use "double standard" as a derogatory term when you're comparing the needs of kernelspace code and userspace code. ...plus, they're already planning to write their own `alloc` replacement if for no other reason that they need to support API features of the kernel allocator that are absent from the userspace allocator, like GFP flags: https://github.com/Rust-for-Linux/linux/issues/2#issuecomment-821143720 https://github.com/Rust-for-Linux/linux/issues/2#issuecommen...

volta83 5y ago
> I don't think you can use "double standard" as a derogatory term when you're comparing the needs of kernelspace code and userspace code. You argue that the needs of kernel space and user space differ when handling OOM errors. If that were true, one wouldn't have had to patch the standard library with the `try_...` methods to try to support OOM handling in user space as an afterthought. That request came from firefox, where a user in userspace can click on a link pointing to a 1 Tb large, e.g., image file, that would kill the browser if it can't handle OOM properly. So yes, it is a double standard, because both user space and kernel space have millions of valid reasons for wanting to handle OOM errors, but Linux and in particular Linus Torvalds motto here is "do as I say, not as I do". It is also extremely ironic that this Linux kernel policy that makes it impossible for user space to handle OOM, now causes Linus to cry about it when the kernel wants to start using tools develop for userspace in the kernel. They are directly responsible for this outcome.
- ssokolow 5y ago
  Rust 1.0 was explicitly intended to be a Minimum Viable Product, containing only the work they felt they couldn't revise later without breaking their API stability promise. As such, they started with the versions of allocating APIs that are most commonly desired... the ones equivalent to how array[index] will either get what you want or panic if you're out of bounds. The try_ allocation APIs which are equivalent to .get on a container then came later. A web browser, while a good program to stress the capabilities of a language's design to make sure it can meet demand, is not a typical program.

volta83 5y ago

> I don't think you can use "double standard" as a derogatory term when you're comparing the needs of kernelspace code and userspace code. You argue that the needs of kernel space and user space differ when handling OOM errors. If that were true, one wouldn't have had to patch the standard library with the `try_...` methods to try to support OOM handling in user space as an afterthought. That request came from firefox, where a user in userspace can click on a link pointing to a 1 Tb large, e.g., image file, that would kill the browser if it can't handle OOM properly. So yes, it is a double standard, because both user space and kernel space have millions of valid reasons for wanting to handle OOM errors, but Linux and in particular Linus Torvalds motto here is "do as I say, not as I do". It is also extremely ironic that this Linux kernel policy that makes it impossible for user space to handle OOM, now causes Linus to cry about it when the kernel wants to start using tools develop for userspace in the kernel. They are directly responsible for this outcome.

ssokolow 5y ago
Rust 1.0 was explicitly intended to be a Minimum Viable Product, containing only the work they felt they couldn't revise later without breaking their API stability promise. As such, they started with the versions of allocating APIs that are most commonly desired... the ones equivalent to how array[index] will either get what you want or panic if you're out of bounds. The try_ allocation APIs which are equivalent to .get on a container then came later. A web browser, while a good program to stress the capabilities of a language's design to make sure it can meet demand, is not a typical program.