Supporting Linux kernel development in Rust • Hacker News Board

Re: Supporting Linux kernel development in Rust

#281

Post by pornel » Tue, Sep 01, 2020, 11:35 AM UTC

ifmpx wrote: post #155

egberts1 wrote: post #125

So glad that Rust at 1.38 ditched the Ada model of compiling all dependent modules firstly.

Can you please expand further on what you mean by this? Are you saying that rustc is compiling a crate before its dependencies?

Compilation in Cargo has been split into metadata pass and code generation pass. Metadata part has interdependencies, but is relatively fast (it's roughly like a C header generation). This allowed more codegen to be done in parallel.

To be honest, it was a modest improvement, because compilation has been decently parallelized already (compiler uses incremental builds, parallel codegen, and ThinLTO even within a single crate)

Re: Supporting Linux kernel development in Rust

#282

Post by pjmlp » Tue, Sep 01, 2020, 11:36 AM UTC

_ph_ wrote: post #276

pjmlp wrote: post #259

Earlier quoted context omitted.

With GPL there is a legal tool to force contribution, though. As mentioned I don't care, after university my main UNIX platforms were HP-UX, Aix and Solaris with their respective system compilers anyway. Linux is already getting replacement candidates in IoT space via Zephyr, NuttX, mbed, RTOS, Azure RTOS, and who knows if Fuchsia will eventually get out of the lab, so be it.

With GPL there is a legal tool to force contribution, though. No, for practical purposes, there is not. You can only enforce delivery of the source when a product based on GPL software gets delivered. But of course companies, which create software, know about this. Any usage of GPL software for delivered products only happens after the decision to publish the created software has been made. In doubt, companies tend t…

So now Sony gets to deliver PS4 OS and you get zilch, nada, besides a few insignificant pull requests, enjoy the license.

Re: Supporting Linux kernel development in Rust

#283

Post by pornel » Tue, Sep 01, 2020, 11:40 AM UTC

jasonhansel wrote: post #137

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. People underestimate the role of copyleft licenses in preserving long-running FOSS products like GCC, Linux, etc.

A GCC back-end for Rust is incredibly important for FLOSS. Even if the world doesn't switch from C to Rust overnight, Rust creates a negative halo effect for GCC, casting doubt on GCC's future relevance. Rust support in GCC would be a huge win for both projects.

Re: Supporting Linux kernel development in Rust

#284

Post by de_watcher » Tue, Sep 01, 2020, 11:49 AM UTC

qalmakka wrote: post #228

pjmlp wrote: post #217

Earlier quoted context omitted.

GCC has plenty of frontends to choose from. The license was the biggest deal.

Developing a GCC frontend is a massive PITA, and the worst of all it was made purposefully so complicated because of RMS' concerns about closed compilers. He actually brought LLVM's existence onto himself, because it was somewhat clear no one would have bothered writing a new compiler if it had been possible to use it's frontend for other things (even from free software it's hard) and they kept the license as "GPLv2…

The fear of GPLv3 is just an excuse to pull things into proprietary. They became aware of the success of GPL and started to actively lobby against it with what they were able to come up with.

Re: Supporting Linux kernel development in Rust

#285

Post by de_watcher » Tue, Sep 01, 2020, 11:53 AM UTC

qalmakka wrote: post #273

pjmlp wrote: post #241

Earlier quoted context omitted.

Sure, now you get to enjoy all those PS4 optimizations, and watchOS bitcode portability fixes in LLVM.

The point is, these things would have happened no matter what. RMS simply overplayed its leverage, and the magic that kept GCC at the centre of everything for decades broke. If he could just stop being a zealot for a split second and actually tried to understand the situation, he could have maybe been able to foresee that Apple had the people, resources and will to reimplement a whole compiler infrastructure that cou…

RMS didn't overplay anything there. His GPL idea has just become too influential and they started fighting it.

Re: Supporting Linux kernel development in Rust

#286

Post by nix23 » Tue, Sep 01, 2020, 12:31 PM UTC

zokula wrote: post #277

smabie wrote: post #247

Earlier quoted context omitted.

I mean, without Linux the arguably superior BSDs would rule the roost, not commercial unices.

LMAO none of the BSD's have not been superior to Linux in over 20 years. Linux has been faster, more stable and more secure then any of the *BSD's for over a decade now.

>Linux has been faster, more stable and more secure then any of the *BSD's for over a decade now.

Can you prove that? EMC, Netflix and Sony thinks otherwise.

EDIT: And please stop with that LMAO (Sound like a childish Child from reddit)

Re: Supporting Linux kernel development in Rust

#287

Post by nix23 » Tue, Sep 01, 2020, 12:33 PM UTC

pjmlp wrote: post #241

qalmakka wrote: post #228

Earlier quoted context omitted.

Developing a GCC frontend is a massive PITA, and the worst of all it was made purposefully so complicated because of RMS' concerns about closed compilers. He actually brought LLVM's existence onto himself, because it was somewhat clear no one would have bothered writing a new compiler if it had been possible to use it's frontend for other things (even from free software it's hard) and they kept the license as "GPLv2…

Sure, now you get to enjoy all those PS4 optimizations, and watchOS bitcode portability fixes in LLVM.

Something like that?

https://www.phoronix.com/scan.php?page=news_item&px=Sony-Tha...

or that:

https://reviews.llvm.org/D15624

Re: Supporting Linux kernel development in Rust

#288

Post by nix23 » Tue, Sep 01, 2020, 12:40 PM UTC

zokula wrote: post #278

nix23 wrote: post #255

Earlier quoted context omitted.

GCC changed from GPLv2 to GPLv3 which is a stupid license for a compiler (Thanks FSF). I'm happy that LLVM exists, happy that Microsoft, Apple, Linux, and BSD's can use it without that GPLv3 BS.

Cowards love cowardly licenses like BSD, MIT, ISC, and the like.

Thanks for proofing your Mindset.

Re: Supporting Linux kernel development in Rust

#289

Post by Narishma » Tue, Sep 01, 2020, 12:47 PM UTC

stefan_ wrote: post #279

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…

That is a weird way to say "your concerns were entirely correct". Every single proprietary mobile graphics driver uses LLVM for its shader compiler and the lack of copyleft has severely curtailed progress on open-source drivers. Of course none of it goes back to LLVM because updating your production copy of LLVM is just as messy and broken as the non-stable GCC IR you complain about and the fact that OSS development…

> Every single proprietary mobile graphics driver uses LLVM for its shader compiler and the lack of copyleft has severely curtailed progress on open-source drivers.

And you think if they didn't have the option of using LLVM they would have released an open source driver instead? That makes no sense to me.

Re: Supporting Linux kernel development in Rust

#290

Post by c-cube » Tue, Sep 01, 2020, 12:50 PM UTC

ghostwriter wrote: post #193

gpm wrote: post #180

Earlier quoted context omitted.

They are implemented once in a crate on crates.io and similarly re-used. Or in a code base like Linux with some unique requirements they'll be implemented once there and re-used many times there. As it turns out most code isn't datastructures with unique memory requirements (i.e. that can't be implemented in terms of other datastructures), most code just re-uses existing datastructures.

> they are implemented once in a crate on crates.io and similarly re-used. this doesn't automatically prevent the code from containing CVE, does it? > As it turns out most code isn't datastructures with unique memory requirements most code that has been written in Rust so far. But when you enter a territory of OS kernels, unique memory requirements and data structures such as ring buffers and dynamic mutable trees ar…

ATS is also harder to understand[1] (in my experience) and has a fraction of a fraction of the adoption rust managed to get, despite being older. To me that suggests that rust is more approachable, has better documentation, and would be used by more people if supported by the kernel.

[1] and really, I'm an OCaml developer and I can write rust; yet ATS' syntax looks terrible and very complicated. Its website and tooling make it appear like a research language made by one person. I don't know if that's really the case.