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

221–230 of 365 posts

Re: Supporting Linux kernel development in Rust

#221

Post by ogoffart »

geofft wrote: post #116
ogoffart wrote: post #91

> The ubiquitous kmalloc() function, for instance, is defined as __always_inline, meaning that it is inlined into all of its callers and no kmalloc() symbol exists in the kernel symbol table for Rust to link against. This problem can be easily worked around — one can define a kmalloc_for_rust() symbol containing an un-inlined version but performing these workarounds by hand would result in a large amount of manual wo…

Yup - that got a very brief mention in the article as "Google is working on automated C++ conversions"; there's also https://github.com/google/autocxx which builds on top of it. C++ is a richer language than C and has more information about ownership (e.g., if you return a std::string you know how ownership works; if you have two arguments that are a char * and a length it's much less clear), but additional annotatio…

The cpp and cxx crates are two different crates with different goal.

The cpp crate is about convenience, but require the use of unsafe within the rust code.

The cxx crate do extra checks making the rust code safer but needs more boilerplate.

In the case of C however, these type checking are not really possible, as you say.

Re: Supporting Linux kernel development in Rust

#222

Post by JoshTriplett »

pjmlp wrote: post #217
JoshTriplett wrote: post #213

Earlier quoted context omitted.

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

All of those frontends live inside the GCC source tree. Which requires copyright assignment to contribute to. And for a long time, it was difficult to "casually contribute" to GCC; you had to work towards "commit access", and it wasn't anyone's job to review other people's patches, so often it just didn't happen. And there are various other barriers to contribution as well.

LLVM's license was certainly a factor, and I'd never suggest otherwise, but there were many other reasons that GCC couldn't help kick off a wave of language design and experimentation the way LLVM did.

Re: Supporting Linux kernel development in Rust

#223

Post by cutemonster »

frutiger wrote: post #218
geofft wrote: post #205

Earlier quoted context omitted.

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.

Meaning, internal things in chromium change so fast, so you'd slightly wish you could have your custom changes merged into upstream? (I.e into chromium)

So that the ppl at Google would keep your code working? And you didn't need to spend time resolving git merge conflicts, and compilation errors?

But you cannot, because some of those bespoke changes are "secret" and what you make money from? (And maybe some changes are off topic to Google)

I wonder how much time does it take to merge a new chromium version into your repo? Like, hours? Days? Weeks

Re: Supporting Linux kernel development in Rust

#224

Post by zelly »

fractalb wrote: post #203
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…

What if those bigcorps don't merge some improvements for getting an edge over the competitors? And, what if every one of those bigcorps do the same? How would that impact the project in the future?

Already the case for Apple LLVM which has optimizations for Apple Silicon not upstreamed and never will be upstreamed.

Re: Supporting Linux kernel development in Rust

#225

Post by pjmlp »

JoshTriplett wrote: post #222
pjmlp wrote: post #217

Earlier quoted context omitted.

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

All of those frontends live inside the GCC source tree. Which requires copyright assignment to contribute to. And for a long time, it was difficult to "casually contribute" to GCC; you had to work towards "commit access", and it wasn't anyone's job to review other people's patches, so often it just didn't happen. And there are various other barriers to contribution as well. LLVM's license was certainly a factor, and…

No they do not.

GNU Pascal, Modula-2, Modula-3, BASIC and plenty of OEM derived ones were never part of GCC source tree.

I had to study GIMPLE and GCC integration as part of my compiler design studies back in the 90's, using those nice Walnut Creek CD-ROMs.

Re: Supporting Linux kernel development in Rust

#226

Post by dehrmann »

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…

> or they're sufficiently general and easiest to maintain by releasing back upstream

Exactly; maintaining a fork is a big pain. The ongoing cost of keeping it up-to-date is a pretty big incentive to merge it, even if there's not a legal requirement.

Re: Supporting Linux kernel development in Rust

#227

Post by adrianN »

fractalb wrote: post #210
Spivak wrote: post #105

Earlier quoted context omitted.

Compile C to Rust! Easiest language migration ever.

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.

Re: Supporting Linux kernel development in Rust

#228

Post by qalmakka »

pjmlp wrote: post #217
JoshTriplett wrote: post #213

Earlier quoted context omitted.

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

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 or later" instead of pushing for v3 that arguably makes 0 sense with GCC (it's not like it's going to be put in a closed box any time soon).

Sometimes in life it's better to be a bit heterodox, but have influence and leverage, than being alone on your high castle. GCC can be as open as it gets, but pushing people away in the name of freedom has actually only given reasons to the industry to move away from it, which is sad and could be avoided.

Re: Supporting Linux kernel development in Rust

#229

Post by roca »

ghostwriter wrote: post #199
roca wrote: post #190

Earlier quoted context omitted.

"In the wild" one hardly ever has to write unsafe Rust data structures and algorithms. > If the motivation to bring a new tool is pronounced as "let's make it safe", why should we allow the argument to fallback into the "unsafe Rust" territory? Because going from 0% of code proven safe by the compiler to 99% is very valuable. Verifying the remaining code is desirable but not as valuable as what Rust already provides.…

> "In the wild" one hardly ever has to write unsafe Rust data structures and algorithms. one has to do it all the time if cyclic mutable graphs or specific buffers/caches are involved. > Verifying the remaining code is desirable but not as valuable as what Rust already provides. How do we know that? What are the criteria and the thresholds that lead us to that conclusion? Is it true for all fields where the language…

I can have cyclic graphs with mutable data without writing any unsafe code: https://docs.rs/petgraph/0.5.1/petgraph/

"Specific buffers/caches" is ambiguous. For embedded systems there are crates that provide safe interfaces to memory-mapped hardware.

You will likely argue that using unsafe code in a library is just as bad as writing unsafe code, even if that library is used and tested by a lot of people and the unsafety is corralled behind a safe API. You would be wrong.

> How do we know that? What are the criteria and the thresholds that lead us to that conclusion?

My current project is 170K lines of Rust code, and has 225 uses of unsafe. That's about 1.3 uses of 'unsafe' per 1000 lines of code. If I could write C++ code and introduce less than 2 exploitable vulnerabilities per 1000 lines of code I'd have an even higher opinion of myself than I already do.

> Is it true for all fields where the language can be used?

I'm sure we're both imaginative enough to dream up some "field" narrow enough to disprove any universally quantified proposition.

> What should we do about inability to express more precise constraints at compile time?

We should adopt proof systems that let us verify safety properties for those little bits of unsafe Rust code. We should not, however, make that a precondition for writing that vast majority of code that can be written in safe Rust in safe Rust.

> Shall we stop on Rust, or try to embrace more powerful tools that already support Dependent Types in low-level systems programming?

That is a false dichotomy.

Safe Rust is a sweet spot where the compiler and tools can verify a strong set of safety properties without the developer having to deal with proof systems and dependent types, with lots of engineering to produce helpful messages when things go wrong. Plus a large library ecosystem that, among other things, provides lots of safe abstractions over unsafe code. Trying to put the brakes on Rust and get everyone to buy into ATS instead is putting the needs of the few over the needs of the many.

Re: Supporting Linux kernel development in Rust

#230

Post by rapsey »

nielsbot wrote: post #204

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

Not even remotely as difficult as Swift. Rust can call into C at any time. It is ABI compatible and has no VM
Post reply on HN