Methinks machine code and assembly is the way to go not high level pussification of the kernel.
Supporting Linux kernel development in Rust
211–220 of 365 posts
Re: Supporting Linux kernel development in Rust
#212We built a whole BPF tool chain for rust :), although not for kernel development.
https://github.com/solana-labs/rust
If this kind of seems interesting please send us a CV.
Re: Supporting Linux kernel development in Rust
#213I'm concerned about the gradual move from GCC to LLVM. The lack of copyleft protections on LLVM means that it's much more dependent on corporate sponsorship, and means that there's a risk that major improvements to LLVM compilers will only become available as proprietary products. People underestimate the role of copyleft licenses in preserving long-running FOSS products like GCC, Linux, etc.
I am even more concerned about LLVM monoculture. LLVM is just a proprietary-able version of GCC. And thus compiler authors mostly focus on benchmarks while not caring about other metrics such as compilation speed, correctness and codebase quality / ease of contribution. There appears to be some tribal knowledge requirement to add a new target. With all the hype and apple funding LLVM gets, it could have been better.
> LLVM is just a proprietary-able version of GCC.
It isn't just that. It's also a compiler framework, somewhat usable as a library without being part of its codebase. And I really do mean somewhat usable; the LLVM experience for use as a library is not great, but it's wildly better than GCC's. I think that, not just the license, is a big part of what made LLVM successful.
Re: Supporting Linux kernel development in Rust
#214Earlier quoted context omitted.
> they're sufficiently general and easiest to maintain by releasing back upstream (where Apple, Google, and Microsoft will pay a small army of compiler engineers to keep them working). ...keep them working for their use-cases .
> keep them working for their use-cases Are you under the impression that C and C++ code within Apple, Microsoft, and Google is fundamentally different from C and C++ code elsewhere? Because it isn’t. Google’s engineers maintain LLVM’s ASan for their purposes, but those purposes happen to be everybody else’s as well.
It may not be fundamentally different but it may only use a subset of features (e.g., no exceptions in C++ code) and/or target a subset of platforms. Without pointing fingers, I am sitting on (what looks to be) a codegen bug in Clang that is not of a high priority I am pretty sure due to the above reasons.
This is not to say that I am not appreciative of all the work Google/Apple/etc engineers do in LLVM (I will be eternally grateful for the Clang targeting MSVC work).
Re: Supporting Linux kernel development in Rust
#215I'm concerned about the gradual move from GCC to LLVM. The lack of copyleft protections on LLVM means that it's much more dependent on corporate sponsorship, and means that there's a risk that major improvements to LLVM compilers will only become available as proprietary products. People underestimate the role of copyleft licenses in preserving long-running FOSS products like GCC, Linux, etc.
Yes, we are short of getting back into the days of Shareware and PD, and then the anti-GPL crowd will be happy with the outcome.
As commercial software user, I don't have much issue with it, after all I have been coding since the early 80's.
And in spite of it and my occasional Linux rants, I am thankful for GPL, because without it there wouldn't be a UNIX to install at home to get my university work from DG/UX done without having to spend one hour traveling into the campus and fighting for a terminal.
Without Linux + GNU based userspace, the commercial UNIXes would all be around.
Re: Supporting Linux kernel development in Rust
#216I'm concerned about the gradual move from GCC to LLVM. The lack of copyleft protections on LLVM means that it's much more dependent on corporate sponsorship, and means that there's a risk that major improvements to LLVM compilers will only become available as proprietary products. People underestimate the role of copyleft licenses in preserving long-running FOSS products like GCC, Linux, etc.
> I'm concerned about the gradual move from GCC to LLVM. The lack of copyleft protections on LLVM means that it's much more dependent on corporate sponsorship, and means that there's a risk that major improvements to LLVM compilers will only become available as proprietary products. As someone who works within LLVM professionally, I don't think this is particularly likely -- compilers are massive and complicated beas…
I don't consider the improvements that ARM, Apple, Sony, CodePlay, NVidia, AMD, among others, don't upstream due to IP considerations or revealing of hardware secrets, niche.
Re: Supporting Linux kernel development in Rust
#217Earlier quoted context omitted.
I am even more concerned about LLVM monoculture. LLVM is just a proprietary-able version of GCC. And thus compiler authors mostly focus on benchmarks while not caring about other metrics such as compilation speed, correctness and codebase quality / ease of contribution. There appears to be some tribal knowledge requirement to add a new target. With all the hype and apple funding LLVM gets, it could have been better.
> LLVM is just a proprietary-able version of GCC. It isn't just that. It's also a compiler framework , somewhat usable as a library without being part of its codebase. And I really do mean somewhat usable; the LLVM experience for use as a library is not great , but it's wildly better than GCC's. I think that, not just the license, is a big part of what made LLVM successful.
GCC has plenty of frontends to choose from.
The license was the biggest deal.
Re: Supporting Linux kernel development in Rust
#218Earlier quoted context omitted.
> keep them working for their use-cases Are you under the impression that C and C++ code within Apple, Microsoft, and Google is fundamentally different from C and C++ code elsewhere? Because it isn’t. Google’s engineers maintain LLVM’s ASan for their purposes, but those purposes happen to be everybody else’s as well.
Right, the reality is that if you want to be a profitable tech company today, you have to leverage open source. "Their use cases" includes, like, everything in a Linux distro. (And yes, this applies to Apple and Microsoft as well as Google.) The necessity of open source for industry has both negative and positive implications for those of us who care about open source / free software as an ideal and not simply a tool…
> One common strategy, used by Linux itself, is to maintain a high level of internal API churn coupled with genuinely good improvements in that churn
Interesting angle that I had never thought of as deliberate. As someone who works on a (bespoke) integration/embedding of Chromium, I could say exactly the same thing about it too.
Re: Supporting Linux kernel development in Rust
#219Sounds like they have the same problem Apple's Swift does for calling into C/Obj-C. Two examples: My understanding is that there's a ton of code and added complexity in Swift itself to support Obj-C interoperation. And while you can call C and Obj-C APIs, as-is, there was/is basically a company-wide effort to write API wrappers (aka. overlays) for existing system APIs. For the second part, maybe if Rust for Linux ker…
This is mostly just a random tidbit but one of the fascinating things to me about Swift ObjC interop is that it's not just that Swift was modified for ObjC, but ObjC was modified for Swift as well. In general it works pretty well and I wonder how much of that is because Apple can modify ObjC whenever it wants.
Re: Supporting Linux kernel development in Rust
#220Earlier quoted context omitted.
> C++ hasn't seemed to have changed that, either. C++ is not like C. Putting some C++ objects in a C codebase would, indeed, not change it much, but if you write in modern C++, some memory errors will literally disappear, and some become less likely. Caveat: This is based on language mechanics, standard library facilities and recommended idioms; of course people can write unsafe C++ if they want to.
And modern C++ features makes some memory errors more likely, e.g. dangling references from lambda captures and string_view/span. I'm not optimistic about the safety of modern C++. Most people who really care about safety long ago left the C++ building.
Some of us are in the managed language world now, the problem is that C++ still has the best integration story with Java and .NET codebases, which Rust still needs to catch up to.
So modern C++ will have to do for the few cases that require going out of them, e.g. runtime plugins for native agents, COM/UWP with access to OS APIs, IDE mixed language debugging, GUI components.
Also there is the whole issue that GPGPU shaders and Apple/Google/MS driver stacks are mostly about C++.
So one either does managed language + C++, or managed language + C++ + additional glue effort + Rust, not much to win currently.