4 ms·

Yeah, the bespoke ways the kernel does things makes me wonder if a linux-kernel-specific language could be a good idea. Almost certainly not, but I think that R

by mastax 4y ago

Yeah, the bespoke ways the kernel does things makes me wonder if a linux-kernel-specific language could be a good idea. Almost certainly not, but I think that Rust/Nim/Zig/Carbon/etc. have shown that it's not insurmountably hard get a new language up to standard nowadays, mostly thanks to LLVM. > Klint doesn't provide a way to prevent code from doing the wrong thing, it only acts a checker that things have been done right (probably). That's cool (and very useful), but quite different from e.g. "you can't make this mistake in Rust". I don't disagree, really, but I'm trying to get a more precise idea about the distinction. Let's pretend that klint makes all the improvements listed in "future work" and all kernel developers `alias rustc=klint`. Is it any worse than the borrow checker or the type system with respect to "only [acting as] a checker that things have been done right"?

PaulDavisThe1st 4y ago
I don't know of any bespoke solutions in the kernel that belong in a language. RCU does not belong in a language. Spinlocks do not belong in a language. etc. etc. These are things that belong in libraries/modules, which leads me to think that there's absolutely zero need for a (linux) kernel specific language.
- tialaramex 4y ago
  The kernel's extended BPF is in fact an entire virtual machine and so necessarily has a virtual machine language. Arguably it would be better if that software was written in a language intended to be translated into eBPF rather than in C, C++ or Rust compiled for the eBPF virtual machine. EtA: Also, while the kernel does have some mechanisms which exist elsewhere, the kernel also has its own memory model, distinct from the C++ (and eventually C) memory model, because Linux has been here a long time and needed a model before C++ had one. So this means there's a conflict between what the ISO document says (based on its memory model) and how Linux works (based on its memory model). So it might be easier on folks if the Linux memory model wasn't just a different memory model for the C language which already has a memory model. That applies just as well for Rust.

by mastax 4y ago

PaulDavisThe1st 4y ago

I don't know of any bespoke solutions in the kernel that belong in a language. RCU does not belong in a language. Spinlocks do not belong in a language. etc. etc. These are things that belong in libraries/modules, which leads me to think that there's absolutely zero need for a (linux) kernel specific language.

tialaramex 4y ago
The kernel's extended BPF is in fact an entire virtual machine and so necessarily has a virtual machine language. Arguably it would be better if that software was written in a language intended to be translated into eBPF rather than in C, C++ or Rust compiled for the eBPF virtual machine. EtA: Also, while the kernel does have some mechanisms which exist elsewhere, the kernel also has its own memory model, distinct from the C++ (and eventually C) memory model, because Linux has been here a long time and needed a model before C++ had one. So this means there's a conflict between what the ISO document says (based on its memory model) and how Linux works (based on its memory model). So it might be easier on folks if the Linux memory model wasn't just a different memory model for the C language which already has a memory model. That applies just as well for Rust.