Linus's initial reaction: https://lkml.org/lkml/2021/4/14/1099
I am pleased that these are all addressable things. We'll see!
I am pleased that these are all addressable things. We'll see!
I actually loved (I mean really loved) reading the response as it not only was encouraging but also highly respectful and almost glowing with a trained sort of nuance! Just wow!
I agree that I found his messages here to be quite pleasant.
Honestly it's really impressive, IMO, that someone could take a look at how they act and think "I should change this," and then actually do it.
It's just that on occasion he would rant and rave to people and call them retards or whatnot. People get a bit of a skewed perception because only those messages make the news and are famous, but that's not really representative of all the messages.
And when he did rant and rave, it was pretty much always towards established contributors who had screwed up somehow; people who in his opinion ought to know better, and most of the time he did have a good point. I don't approve of his style, but it's not like he would randomly call people idiots. It's not as if you ever ran the risk of being scolded by Linus if you were a new contributor sending a patch or anything.
tl;dr: Linus has always been like this, and was just occasionally an asshole.
Quite frankly I consider most of the news to be worse than useless and actively harmful (and news is different from journalism; journalism is great).
(also, I see now I misspelled constructive as "constrictive" in my previous comment do'h facepalm)
Indeed, and I hate it. It's actually very scary, a creepy change in personality. Like the last scene in "one flew over the cuckoo's nest", where the main character is lobotomized and loses the spark on his eyes. Deeply, deeply troubling to behold. I wonder if the real Linus still exists behind all this or he's gone forever.
As with most human beings Linus is a person with different responses to different things and is generally not a complete lemon.
The persona of Linus you get from following LKML has always been different than the persona you'd get from internet gossip.
Also, I think what's really interesting is that with his feedback, could the language be actually be adapted to the kernel?
This would be fascinating because traditionally the code (the kernel in this case) has to adapt to the foibles of C. This could be the reverse, where not only could the language adapt, it might make the kernel technically better, and easier to read and modify.
This RFC is accepted and implemented. See the Josh's answer[2].
[1]: https://github.com/rust-lang/rfcs/blob/master/text/2116-allo... [2]: https://lore.kernel.org/lkml/YHdSATy9am21Tj4Z@localhost/
Also, RFC 2116 assumes that it's sufficient to provide (for instance) Vec::try_reserve, and require callers to always call that before calling anything that might expand the Vec. That wouldn't eliminate the runtime panics. It might be necessary to go a step further, and actually provide fallible versions of individual Vec methods. (Or there may be other potential solutions.)
A bunch of us, anticipating a reaction like Linus' have been arguing that we need `try_` versions of everything and* a way to prevent the other ones from being used. (Cargo features?) I sincerely hope we finally get that.
let v = vec![0; 42];
v.try_reserve(1);
frob(&mut v); // I expect this not to expand the array
v.push(1); // fails, because frob took the space
One option for avoiding this would be to pass a mutable reference to a slice, which allows frob to mutate elements of the vec without allowing it to push.
frob(&v[..])
But it's still non-local. one has to manually account for what allocation will be done, and keep the reservation in sync across refactors. This isn't a race but still scares me.
Someone could write
shared_v.lock().try_reserved();
shared_v.lock().something();
This has been anticipated since panic on OOM was introduced.
Adding `try_` version of everything is a horrible solution.
What you want is for the normal APIs to return Result<R,E> where E=! when panic on OOM and some OOM error otherwise.
The largest irony of all time is that, while returning an error on OOM works well on Windows, it makes little sense on Linux because overcommit is often enable by default. Linux and Linux users are directly responsible for the "panic on OOM" that turns out now prevents liballoc from being used in the Linux kernel.
The obvious fix here is for the kernel to use overcommit internally \s
That's a fun idea! I haven't seen that proposed before, but it would work well once we have the ability to configure std and alloc.
The most notable way this can go wrong in pure Rust code is that panic-while-panicking aborts. So you have to be careful that your destructor can never panic.
It's kind of a funny space; right now Rust handily gives you "no allocations" (this is where I live) or "infallible + fallible allocations" (this is alloc/std by default) but not "only fallible allocations". This sort of thing is basically filling out the quadrant of options.
Rust in the kernel is not a simple thing, but I think both rust and the kernel will benefit.
It's pretty hacky, but it works on no_std.
> So "Result<T, E>" is basically the way to go, and if the standard Rust library alloc() model is based on "panic!" then that kind of model must simply not be used in the kernel.
It just makes things slower to compile and less portable.
[1]: https://www.kernel.org/doc/html/v4.15/process/stable-kernel-...
See https://en.wikipedia.org/wiki/C0_and_C1_control_codes and https://en.wikipedia.org/wiki/ASCII
In programmer lingo it can means something similar to the original meaning--rejecting a request for faultiness or incompleteness--or it can mean something more like, "no"--answering in the negative.