Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supporting Linux kernel development in Rust

lwn.net

Post reply on HN
Print view View original

271–280 of 365 posts

Re: Supporting Linux kernel development in Rust

#271

Post by pjmlp »

GoOnThenDoTell wrote: post #201
ColanR wrote: post #27

Earlier quoted context omitted.

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…

Apple IOKit

Already in replacement process by Driver Kit and the long term roadmap to migrate all kernel extensions to userspace.

Re: Supporting Linux kernel development in Rust

#272

Post by pjmlp »

kbenson wrote: post #117
ghostwriter wrote: post #81

Earlier quoted context omitted.

> It's also not limited to Rust, it's about providing support for multiple other languages that could be beneficial in those locations But what are these benefits that other languages bring on the table? From the article it appears that proponents of the new toolchain mention memory-safety as the primary concern: > They focused on security concerns, citing work showing that around two-thirds of the kernel vulnerabili…

> But what are these benefits that other languages bring on the table? From the article it appears that proponents of the new toolchain mention memory-safety as the primary concern: Of the venn diagram of languages that provide more safety than C (and that is, either require it or make it hard to bypass), and languages that people know know or are likely to know in the semi-near future, Rust and Go are probably the b…

Followed by Java, .NET (AOT compiled), and Swift, I would say.

In fact it would be nice to have eBPF backends for them as well, naturally only possible for specific language subsets.

Re: Supporting Linux kernel development in Rust

#273

Post by qalmakka »

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.

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 could threaten GCC's dominance, but he neglected it (it famously didn't care about Apple's offer to merge LLVM into GCC under the GPL).

Sometimes even the best of intents are shadowed by people's inability to compromise.

Re: Supporting Linux kernel development in Rust

#274

Post by pjmlp »

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…

That magic was UNIX vendors started to charge for their compilers, and as we have seen by the BSDs have taken the world of UNIX clones.

Sometimes the hate for a license prevents people to grasp what is ahead of them.

Re: Supporting Linux kernel development in Rust

#275

Post by RMPR »

aey wrote: post #212

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

Do you have some kind of official blog for this? I'm interested in BPF and currently learning Rust, would love to learn more about this.

Re: Supporting Linux kernel development in Rust

#276

Post by _ph_ »

pjmlp wrote: post #259
_ph_ wrote: post #252

Earlier quoted context omitted.

They don't upstream what they never would be up streamed. But they probably they upstream a lot which they wouldn't have, if they couldn't use the open source tool at all. Also, a lot of companies reduce their development costs by using open source software, gpl or other, without ever upstreaming. So "saving development cost" doesn't sound like an argument to me.

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 to not use GPL software as part of deliveries.

Re: Supporting Linux kernel development in Rust

#277

Post by zokula »

smabie wrote: post #247
pjmlp wrote: post #215

Earlier quoted context omitted.

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…

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.

Re: Supporting Linux kernel development in Rust

#278

Post by zokula »

nix23 wrote: post #255
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.

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.

Re: Supporting Linux kernel development in Rust

#279

Post by stefan_ »

woodruffw wrote: post #162
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.

> 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 is still fundamentally incompatible with 1-year industry release schedules that shift all the time.

Post reply on HN