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

61–70 of 365 posts

Re: Supporting Linux kernel development in Rust

#61

Post by kbenson »

ghostwriter wrote: post #30

I won't get tired of repeating the same comment in every topic that suggests Rust to be a great replacement of C in existing projects , that it isn't. The safety guarantees that Rust provides are neither unique nor complete, and if we discuss the amount of effort necessary for bringing new interfaces like the one this article mentions ("one can define a kmalloc_for_rust() symbol containing an un-inlined version"), we…

> I won't get tired of repeating the same comment in every topic that suggests Rust to be a great replacement of C in existing projects, that it isn't.

That's not what this is about, so even though you aren't tired of posting this, I'm not sure it's warranted.

This is about the kernel supporting other languages in select places where it makes sense, such as kernel modules, where there's already an API in place to conform to. It's also not limited to Rust, it's about providing support for multiple other languages that could be beneficial in those locations.

> I won't get tired of repeating the same comment in every topic that suggests Rust to be a great replacement of C in existing projects, that it isn't.

Nobody is giving up on existing C interfaces. They are simply making sure those interfaces are not actively hostile to languages that aren't C by nature of how they are implemented in C.

To be clear, the "kmalloc_for_rust" was mentioned as one possible way forward. Another would be a more advanced Rust bindgen tool that can determine how to deal with it automatically. Neither affect ATS, based on your description (although a "kmalloc_for_extern" might generally help any non-C language, which would probably be beneficial).

If ATS doesn't require any changes to C to interoperate with it, this whole announcement should have zero impact on ATS, other than possibly making it easier to get an ATS module in-kernel since they're trying to make it easier in general for non-C modules.

You can treat this as a zero-sum gain, where Rust or Go's gain is ATS' loss, in which case you might as well pack up your bags now, since the writing is on the wall based on publicity, or you can treat it as a rising tide raises all boats type situation, where more general acceptance of alternatives to C is still beneficial to ATS actually being allowed in-kernel, even if it doesn't play exactly to ATS' strengths. I know which one I would put my money behind as being a better strategy in the end.

Re: Supporting Linux kernel development in Rust

#62

Post by ekidd »

ghostwriter wrote: post #30

I won't get tired of repeating the same comment in every topic that suggests Rust to be a great replacement of C in existing projects , that it isn't. The safety guarantees that Rust provides are neither unique nor complete, and if we discuss the amount of effort necessary for bringing new interfaces like the one this article mentions ("one can define a kmalloc_for_rust() symbol containing an un-inlined version"), we…

Yes, I've seen this comment a number of times now.

ATS is a very interesting language! But there are a wide range of options for formal verification of systems programs, including the techniques used for the formally verified seL4 kernel, ATS, recent Ada work, TLA+, etc. Some of these tools have been very successful for certain projects.

But the more powerful proof systems involve tradeoffs. Frequently, you need to invest significant amounts of developer effort in exchange for very rigorously proven code. I've played with a number of these systems over the years, and they're great. But the costs would be hard to justify for many projects.

Rust occupies a slightly different niche. It focuses on preventing several classes of memory errors and data races. It's certainly harder to learn than Python, but probably easier than some common subsets of C++.

So the right tool for the job depends on what you're trying to do. If you want to formally verify your kernel's security model, or your distributed protocol, Rust would be a poor choice. If you want a language that makes it easy to work within sight of the metal, and that takes pains to make expensive operations visible, Rust can be a reasonable choice.

Re: Supporting Linux kernel development in Rust

#63

Post by rumanator »

stmw wrote: post #48
ghostwriter wrote: post #30

I won't get tired of repeating the same comment in every topic that suggests Rust to be a great replacement of C in existing projects , that it isn't. The safety guarantees that Rust provides are neither unique nor complete, and if we discuss the amount of effort necessary for bringing new interfaces like the one this article mentions ("one can define a kmalloc_for_rust() symbol containing an un-inlined version"), we…

ATS certainly looks interestinb, but it's an academic language (of which there are many) that most people probably haven't heard of... At some point, the momentum of a new programming language is just as important -- in practical terms -- as its formal attributes and qualities.

Your centering your criticism of ATS on popularity. Does an investment on PR trumps technical merit?

Re: Supporting Linux kernel development in Rust

#64

Post by aspaceman »

JoshTriplett wrote: post #29
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…

The point of this LPC session was how to incrementally introduce Rust in the existing Linux kernel, with all its existing drivers and syscalls and similar. A rewrite would indeed be a daunting and problematic proposition. There are kernels written in Rust, such as Redox, but those are separate projects, and that's not what this conference session or article are talking about. Standing reminder: the Rust project is no…

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

Re: Supporting Linux kernel development in Rust

#65

Post by gameswithgo »

ghostwriter wrote: post #30

I won't get tired of repeating the same comment in every topic that suggests Rust to be a great replacement of C in existing projects , that it isn't. The safety guarantees that Rust provides are neither unique nor complete, and if we discuss the amount of effort necessary for bringing new interfaces like the one this article mentions ("one can define a kmalloc_for_rust() symbol containing an un-inlined version"), we…

>The safety guarantees that Rust provides are neither unique nor complete,

Well no language can ever have "complete" safety guarantees. But I would like to know what other languages offer the same set of guarantees without GC overhead. This would include:

* the usual memory safety * no nulls * no undefined behavior * no data races

Does ATS guarantee those things?

Re: Supporting Linux kernel development in Rust

#67

Post by AquaLineSpirit »

AquaLineSpirit wrote: post #55
dijit wrote: post #11

Earlier quoted context omitted.

I'm generally in support of rust in the kernel, but in the interest of playing devils advocate: Would adding more and more dependence on rust mean that it ties the kernel to a single set of compilers? I can see why people would be opposed to that. I'm thinking about LLVM (and, obviously, rustc)

There is the mrustc compiler https://github.com/thepowersgang/mrustc It's not fully complete. But there is no reason why it couldn't be.

Also it would be kind of funny. Where the rust parts can only be compiled by the llvm based rust compiler, but clang(llvm) can't build the C parts. And gcc can only build the C parts but not the rust parts :)

Re: Supporting Linux kernel development in Rust

#68

Post by ghostwriter »

johncolanduoni wrote: post #52
ghostwriter wrote: post #49

Earlier quoted context omitted.

> Your evidence (that there are potentially other alternatives) doesn't support your claim (that Rust isn't a great C replacement). I didn't claim that Rust isn't a great replacement overall, I was specifically mentioning that it's not great for existing C codebases, by the fact that it requires significant work to replace internal interfaces that may be important for performance-, backward-compatibility- and convent…

How does ATS provide safety guarantees without additional semantic information about the C code it’s linking to? If it does require that, then you’re in the same boat as Rust: your choices are trivial interoperation with no safety at the interfaces or encoding the semantics of the C interface in the new language. The only difference I can think of is built in ability to inline C from headers (based on your comment ab…

It's not only inclusion of the headers. ATS compiles to C, and it can inline C without FFI. The benefit that you receive is the ability to introduce gradual automated proofs around unchanged stable interfaces that are known to be safe. You start with inlining everything but the small core that is proven to be safe. Then you can iterate indefinitely at the desired pace to bring new layers of formally verified API in places of previously unverified C calls without breaking backward compatibility and expected runtime profiles (safe pointer-based memory access [1] and stack-allocated closures [2] as an example)

[1] http://www.ats-lang.org/MYDATA/SPPSV-padl05.pdf

[2] http://ats-lang.github.io/DOCUMENT/ATS2TUTORIAL/HTML/c1267.h...

Re: Supporting Linux kernel development in Rust

#69

Post by dmitrygr »

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…

in some ways, this is how Service Console works in vmware ESX: https://en.wikipedia.org/wiki/VMware_ESXi

Re: Supporting Linux kernel development in Rust

#70

Post by boogies »

JoshTriplett wrote: post #40
ColanR wrote: post #35

Earlier quoted context omitted.

I think you were being "inaccurate and hyperbolic". > Linux is not "forcing adoption of HDCP" (it's just something Linux has a driver for) What they actually said in the article: > Historically, some features began as optional ones until they reached total functionality. Then they became forced and difficult to patch out. Even if this does not happen in the case of HDCP, we remain cautious about such implementations.

My comment was entirely based on the second link. Direct quote from that: > Linux kernel forcing adaption of DRM, including HDCP. (Which linked to a patch adding driver support for handling HDCP, with absolutely no possibility of it somehow being forced.) Regarding the quote from that interview: sure, and there's also no guarantee that the Linux kernel won't drop support for every architecture except SPARC, except of…

I don’t know about Linux, but Mozilla has mandated many things that I would have hoped it never would have, like XUL depreciation, and especially added many anti-features to their largest product, deciding each was not their hill to die on https://news.ycombinator.com/item?id=24124954. I left Firefox and have never regretted it. The Hyperbola devs did the same, and I will be happy to try their OS and support them fighting on every hill they find, no matter how tiny or unimportant it seems to larger organizations.
Post reply on HN