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

41–50 of 365 posts

Re: Supporting Linux kernel development in Rust

#41

Post by JoshTriplett »

jcranmer wrote: post #38
JoshTriplett wrote: post #32

Earlier quoted context omitted.

Originally, we thought that Linux maintainers were asking us to only support kernels compiled with Clang, because they didn't want to support code built with two different compilers. However, in the session, Greg Kroah-Hartman specifically said that if it works to build Rust code with the LLVM-based rustc and C code with GCC and link the two together, and there aren't any problems in practice, then that's perfectly f…

> unless you want to use cross-language LTO (which we'll eventually want to do, but it won't be a hard requirement for a working kernel). Does Linux even work with LTO right now? It seems to do a lot of weird-linking-magic things that I wouldn't expect to work well with LTO.

At the moment, I believe the Linux kernel can do LTO with some additional patches, but there are still regular issues. It isn't nearly as well supported as Clang or LLD yet.

Re: Supporting Linux kernel development in Rust

#42

Post by captn3m0 »

est31 wrote: post #17
jcranmer wrote: post #5

Earlier quoted context omitted.

If I'm understanding correctly, the only reason for not using Rust is... Rust is trademarked?

Wait till we tell them that Linux is a trademark of Linus Torvalds.

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.

Re: Supporting Linux kernel development in Rust

#43

Post by gpm »

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…

Your evidence (that there are potentially other alternatives) doesn't support your claim (that Rust isn't a great C replacement).

There can be multiple great C replacements.

Not being "perfect" in terms of the guarantees you provide doesn't mean you aren't a great improvement. Nor would not providing any guarantees at all mean that a language is necessarily not a great improvement.

That said, I would be very interested in seeing a comparison between C, Rust, and ATS in practical code. This is the first I'm hearing of ATS and it sounds interesting.

Re: Supporting Linux kernel development in Rust

#44

Post by jcranmer »

cylon13 wrote: post #18
Macha wrote: post #16

Earlier quoted context omitted.

The licensing complaints about Rust apply equally to Python, which they package without objection: https://www.hyperbola.info/packages/extra/x86_64/python/

Not exactly: [0] > Some users have correctly mentioned that many other software packages have trademarks, do we plan to remove them all? No. We are not against all trademarks, only those which explicitly prohibit normal use, patching, and modification. > As an example, neither Python PSF nor Perl Trademarks currently prohibit patching the code without prior approval. They do prohibit abuse of their trademarks, e.g. y…

I suspect whomever wrote that hasn't actually read the trademark policies in detail, or conferred with lawyers about it. Neither Python's nor Perl's agreements explicitly cover the case in detail, but Perl does mention this:

> Licensed redistributors of Perl code are permitted by their licenses to use the Perl logo in connection with their distribution services, on product packaging, and in promotional materials.

IANAL, but that text would especially suggest to me that you would have no right to use the trademark even to distribute an unmodified binary of Perl without approval.

I suspect the real reason is Debian and Mozilla had a very public, well-known spat over licensing, and Python and Perl have not had very public, well-known spats with anybody.

Re: Supporting Linux kernel development in Rust

#45

Post by stmw »

muricula wrote: post #23
stmw wrote: post #13

Earlier quoted context omitted.

Can you elaborate re: issues and lots of work required? I think it's generally to be expected that non-C language support in the kernel would be hard...

Here's the article the parent mentioned in passing, it may answer your question: https://www.chromium.org/Home/chromium-security/memory-safet... It's very Chrome and C++ specific, but the problems will likely be similar in practice.

Ah, right, I'd read that - but it's for C++, so it's a bit different than the kernel situation, and I actually had a much more positive reaction to it ("wow, seems like C++Rust is actually pretty far along"). Guess both are reasonable takeaways.

Re: Supporting Linux kernel development in Rust

#46

Post by joshuawarner32 »

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’m glad that there other efforts for memory-safety going on concurrently, and we as a software community should absolutely continue to invest in those. I also agree that rust is not suited for all circumstances that people try to use it in - but I would contend that the set of situations where rust is absolutely the right choice is non-empty. I say this as part of a ~20 person team, rewriting business-critical software in Rust, where most of the engineers I talk with are glad they’re writing rust.

Re: Supporting Linux kernel development in Rust

#48

Post by stmw »

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.

Re: Supporting Linux kernel development in Rust

#49

Post by ghostwriter »

gpm wrote: post #43
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…

Your evidence (that there are potentially other alternatives) doesn't support your claim (that Rust isn't a great C replacement). There can be multiple great C replacements. Not being "perfect" in terms of the guarantees you provide doesn't mean you aren't a great improvement. Nor would not providing any guarantees at all mean that a language is necessarily not a great improvement. That said, I would be very interest…

> 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 conventional tooling reasons. It doesn't interoperate with C as well as other alternatives are capable of, whilst not being objectively better at safety guarantees either.

Re: Supporting Linux kernel development in Rust

#50

Post by rphln »

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…

I might be wrong, but isn't there already a precedent for something similar in the form of the XNU kernel? From a cursory glance, it is basically a BSD and a Mach kernel running side by side.
Post reply on HN