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

351–360 of 365 posts

Re: Supporting Linux kernel development in Rust

#351

Post by stefan_ »

ptman wrote: post #347
bryanlarsen wrote: post #319

Earlier quoted context omitted.

Sure, if you have the resources of Apple, you can make other choices. I'd be willing to bet that Apple has spent more than $1B on clang, llvm, tooling, testing, integration, et cetera.

How much resources did they actually have in 2005?

That's the wrong question. How much resources does someone have who decides to write an entirely new compiler when a working one already exists?

Of course the answer then reveals that this was only possible because there was comfy GCC to fall back on all along. They started in 2005, Clang became default in XCode with the 4.2 release in October 2011.

Ask yourself if you can sell your manager on 6 years of effort for no functional difference, likely even inferior.

Re: Supporting Linux kernel development in Rust

#352

Post by aspaceman »

progval wrote: post #110
aspaceman wrote: post #64

Earlier quoted context omitted.

> the Rust project is not a fan of rabid Rust over-evangelism (e.g. "Rewrite It In Rust", "Rust Evangelism Strike Force"), and sees it as damaging and unhelpful. I was really caught off guard by this stuff recently. I was around the rust subreddit a lot back in 2013-2015 and never saw stuff like that. Stepped out while working on other stuff and now it seems common. Super strange.

As an occasional rust programmer: you don't see this kind of behavior from the rust community. You see it when a random person opens an issue on a bugtracker you are subscribed to. Then it's usually prompty closed by a maintainer because the issue is very low effort, and the author doesn't offer to do any work themselves. Examples: https://gitlab.com/fdroid/fdroidclient/-/issues/1049 and https://github.com/rapid7/met…

Makes sense. Sorry wasn’t trying to say it’s anyone’s fault at all. Just was weird as someone who’s been on and off that programming for awhile now.

Re: Supporting Linux kernel development in Rust

#353

Post by spott »

bryanlarsen wrote: post #303
Narishma wrote: post #289

Earlier quoted context omitted.

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

Yes. Developing a state of the art optimizing compiler is hard . If their only choices are developing their own compiler or basing off of gcc and releasing their work, they'd choose gcc.

Nah, they license a proprietary one. There are a whole bunch of them (ICC, Digital Mars, PGI before they were acquired by Nvidia...). They generally aren't as good as GCC, but they keep your code private and copy-left licenses away from private codebases.

Re: Supporting Linux kernel development in Rust

#354

Post by est31 »

hyperman1 wrote: post #265
captn3m0 wrote: post #42

Earlier quoted context omitted.

it involves the "patches-must-be-approved-by-upstream" to still be called Rust clause that Rust inherits from the Mozilla Trademark policy. Its the same policy that led to the creation of IceWeasel/Waterfox etc.

Here is the core of the issue: https://lwn.net/Articles/118279/ Debian wanted to allow anyone to patch their firefox. Mozilla said OK, but not with our name attached to it. And this makes sense on some level : No project wants to provide support for someone else's bugs.

For a desktop app it's understandable, but tons of scripts rely on the existence of rustc and cargo binaries. If the fork has to rename it to not-rustc just because it added e.g. gcc support, then that's going to break all the scripts.

Re: Supporting Linux kernel development in Rust

#355

Post by snuxoll »

pjmlp wrote: post #344
snuxoll wrote: post #343

Earlier quoted context omitted.

.Net is a much simpler integration, all of the support is in the CLR because COM defines a limited ABI that can be called from any language that can walk a few pointers in a C++ vtable given an interface definition. One can even completely ignore the RCW/CCW support in .Net entirely and just hack together some struct types that match the vtable layout.

Old style COM yes, UWP supports much more, value types, enumerations, generics, partial support for implementation inheritance (in context of XAML). Also you ignored that .NET was made to fully support C++ via Managed C++, replaced with C++/CLI on version 2.0.

The WinRT ABI does implement some new features, yes - but they’re all still implementable with nothing more than standard C# code with no special support from WinRT itself (in fact, the WinRT ABI integration is being stripped out of the runtime and cswinrt is the way forward).

C++/CLI ultimately still uses the same features the runtime uses for p/invoke calls, though it uses slightly different IL to transition to native code since it doesn’t have to worry about an external ABI within a mixed mode assembly. Sure, there’s a whole compiler that supports this weird mixed mode world from a language perspective - but it’s really boring at runtime.

Re: Supporting Linux kernel development in Rust

#356

Post by pjmlp »

snuxoll wrote: post #355
pjmlp wrote: post #344

Earlier quoted context omitted.

Old style COM yes, UWP supports much more, value types, enumerations, generics, partial support for implementation inheritance (in context of XAML). Also you ignored that .NET was made to fully support C++ via Managed C++, replaced with C++/CLI on version 2.0.

The WinRT ABI does implement some new features, yes - but they’re all still implementable with nothing more than standard C# code with no special support from WinRT itself (in fact, the WinRT ABI integration is being stripped out of the runtime and cswinrt is the way forward). C++/CLI ultimately still uses the same features the runtime uses for p/invoke calls, though it uses slightly different IL to transition to nat…

All of that doesn't change the fact that there is tooling in place, and language features (e.g. dynamic for COM, upcoming C#9 improved native FFI) to ease interoperability between managed and some level of C++.

Something that no UNIX does, and we only find similar ideas in Swift/Objective-C++, IBM language environments, and the old OS/2 SOM (Smalltalk/C++).

While everyone else just writes glue code with C like interfaces, as if the world has hardly changed from UNIX V6.

Re: Supporting Linux kernel development in Rust

#357

Post by progval »

aspaceman wrote: post #352
progval wrote: post #110

Earlier quoted context omitted.

As an occasional rust programmer: you don't see this kind of behavior from the rust community. You see it when a random person opens an issue on a bugtracker you are subscribed to. Then it's usually prompty closed by a maintainer because the issue is very low effort, and the author doesn't offer to do any work themselves. Examples: https://gitlab.com/fdroid/fdroidclient/-/issues/1049 and https://github.com/rapid7/met…

Makes sense. Sorry wasn’t trying to say it’s anyone’s fault at all. Just was weird as someone who’s been on and off that programming for awhile now.

No problem, I didn't take it personally.

Re-reading my comment I realize "you don't see this kind of behavior from the rust community" was unclear. I meant that people who are part of rust community don't see it, because it happens outside.

Re: Supporting Linux kernel development in Rust

#358

Post by eptcyka »

pjmlp wrote: post #348
eptcyka wrote: post #8

Earlier quoted context omitted.

The linux kernel still can only be compiled with GCC. Of course, it's a single patch away from clang compatibility, but the kernel has never been compilable with much else but GCC.

Android and ChromeOS beg to differ, as Google has been using clang with them for at least around three years now.

Yes, clang compatibility is a single patch away. Google, unlike the vast majority of companies out there, is capable of maintaining it's own forks of the kernel.

Re: Supporting Linux kernel development in Rust

#359

Post by nix23 »

pjmlp wrote: post #346
nix23 wrote: post #331

Earlier quoted context omitted.

1/3 of the us internet traffic, not counting Juniper, then add all PS2/3/4 Consoles, MacOS's, FreeNas, EMC-San's: Biggest German Online Seller, Sony Japan, Checkpoint and so on...search for yourself. BTW: Market-share means nothing, you know Android is NOT Gnu/Linux EDIT: Maybe your too young..but do you remember that SCO/Microsoft thingy with Linux

I known, most of them don't contribute that much upstream. I surely remember it, except BSD did not ever had anyone like IBM jumping into the battle. :) As for being young, thanks for the compliment > ...as anyone coding since mid-80's.... And as information, during the early days, the Internet ran on commercial UNIXes.

>IBM jumping into the battle

They did not...the opposite is true, they shat their pants because shortly before they said "yes" to Linux, that's why SCO came...first time you had really big money (IBM) behind Linux, please don't change the timeline...it's kind of important.

>And as information, during the early days, the Internet ran on commercial UNIXes.

What do you wanna say with that? During the early days of Smartphones they ran on commercial OS's??

Re: Supporting Linux kernel development in Rust

#360

Post by aldanor »

pornel wrote: post #283
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.

A win for GCC - for sure. Not sure why that would be a 'huge win' for Rust at all.
Post reply on HN