Supporting Linux kernel development in Rust

Post by [deleted] » Tue, Sep 01, 2020, 6:58 AM UTC

Google234 wrote: post #182

higerordermap wrote: post #178

Earlier 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.

I all see are a bunch of baseless accusations.

Post by fractalb » Tue, Sep 01, 2020, 7:04 AM UTC

adrianN wrote: post #227

fractalb wrote: post #210

Earlier quoted context omitted.

That would eliminate the need for Rust. Just imagine, if your C code can be converted into Rust, would there ever be a case to start a fresh project in Rust? It will permanently become an Intermediate language.

Converting C to Rust is not that hard. Converting C to safe Rust is the difficult part.

Post by sgift » Tue, Sep 01, 2020, 7:11 AM UTC

boris wrote: post #214

woodruffw wrote: post #196

Earlier 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.

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 e…

Post by genghizkhan » Tue, Sep 01, 2020, 7:27 AM UTC

ColanR wrote: post #27

puzzledobserver wrote: post #9

One of the challenges to building an entirely new kernel is the vast amount of hardware support in the form of drivers and the features the existing kernel exports to userland in the form of syscalls. Would it be possible for a hypothetical new kernel, presumably written in Rust, to run an existing kernel such as Linux in a VM, just to tap into its drivers and emulate its syscalls? As more drivers are ported to the b…

I was thinking about something similar recently - if the hardware drivers could somehow be abstracted from the rest of the linux kernel (as if...), then suddenly a ton of experimental kernels could have widespread hardware availability. It would probably shake up the OS ecosystem to no small degree, but I imagine the fresh ideas that could be experimented with by non-experts would be hugely beneficial. Isn't that the…

Post by _ph_ » Tue, Sep 01, 2020, 7:37 AM UTC

pjmlp wrote: post #216

woodruffw wrote: post #162

Earlier quoted context omitted.

> 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.