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

51–60 of 365 posts

Re: Supporting Linux kernel development in Rust

#51

Post by JoshTriplett »

joshuawarner32 wrote: post #46
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 softw…

It's certainly not just about safety. It's about the combination of safety, expressiveness, productivity, and various other factors.

Re: Supporting Linux kernel development in Rust

#52

Post by johncolanduoni »

ghostwriter wrote: post #49
gpm wrote: post #43

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). 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 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 about kmalloc), is that the case for ATS?

Re: Supporting Linux kernel development in Rust

#53

Post by JoshTriplett »

gpm wrote: post #22
Thaxll wrote: post #3

Looks like there is a lot of work involved to have anything done, remind me the issues that the Chrome team said 2 weeks ago.

There is no doubt a lot of work here, but C Rust interoperability is a lot cleaner than C++ Rust. And for what it's worth, for almost all langauges C X interoperability is a lot cleaner than C++ X. Since almost all languages (including rust) "speak C", both in terms of compiler support and and being able to map every important C concept to a concept in their language. The same isn't true with C++. One thing to worry…

> One thing to worry about with adding any language (including rust) to the kernel, is that the next good looking language will probably interoperate well with C and not interoperate well with Rust. So there is a much higher cost the second time you try to add a language.

This is something that Rust is acutely aware of. There have been many discussions about the idea of a higher-level "safe ABI", such that languages with notions like counted strings or bounded buffers could interoperate with each other without having to go by way of an unsafe C interface.

Re: Supporting Linux kernel development in Rust

#54

Post by el_oni »

homarp wrote: post #31
guerrilla wrote: post #10

Earlier quoted context omitted.

I'm not sure, but aren't they saying that they wouldn't be able to call it "GNU Rust" [1] in the same way they can't call IceCat "GNU Firefox"? 1. https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...

well, plenty of names to play with:) GNR: Gnr Not Rust TRust: Treated Rust ...

Or something like "oxide", ferrite, maGNUtite. Play with iron ores or compounds

Re: Supporting Linux kernel development in Rust

#55

Post by AquaLineSpirit »

dijit wrote: post #11
jcranmer wrote: post #5

Earlier quoted context omitted.

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

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.

Re: Supporting Linux kernel development in Rust

#56

Post by boogies »

ColanR wrote: post #35
JoshTriplett wrote: post #15

Earlier quoted context omitted.

The vast majority of the text in that post is inaccurate and hyperbolic. Linux is not "forcing adoption of HDCP" (it's just something Linux has a driver for), Rust does not require internet access to use (and the trademark comments are not particularly accurate either), the Kernel Self Protection Project is alive and well and making new improvements in every new version of the kernel (see Kees Cook's regular blog pos…

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.

I was going to comment similarly. The comment could be described as “inaccurate and hyperbolic”: if spelling counts, the second link does not say Linux was “forcing adoption [emphasis added] of HDCP.” Systemd stinks and I don’t care how it’s spelled as long as it’s sent to … nvm. And the Hyperbola devs have shown up, done the work, and ported pacman to their kernel, not making the mistake of listening to hyperbolic haters.

Re: Supporting Linux kernel development in Rust

#57

Post by steveklabnik »

captn3m0 wrote: post #42
est31 wrote: post #17

Earlier quoted context omitted.

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.

The root issue with Iceweasel was the logo, in my understanding. It was also resolved years ago. Rust does not inherit these problems, and even then, Mozilla will not be holding these trademarks anymore, even though I do not expect our policy will change once ownership changes.

We do also, you know, give permission.

Re: Supporting Linux kernel development in Rust

#58

Post by steveklabnik »

_8j50 wrote: post #36
guerrilla wrote: post #10

Earlier quoted context omitted.

I'm not sure, but aren't they saying that they wouldn't be able to call it "GNU Rust" [1] in the same way they can't call IceCat "GNU Firefox"? 1. https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...

They can call it something else entirely. Rusty? Brown? Who cares so long as it is compatible with rustc

If it is compatible with rustc, then we would probably approve a request to use the trademark.

Re: Supporting Linux kernel development in Rust

#59

Post by ghostwriter »

joshuawarner32 wrote: post #46
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 softw…

> but I would contend that the set of situations where rust is absolutely the right choice is non-empty

Maybe I should've highlighted it in my initial comment, because I definitely agree that this list is non-empty for Rust. I was mentioning specifically existing C codebases that are heavily used in production around the world (last time a similar topic was related to QUEMU project).

Re: Supporting Linux kernel development in Rust

#60

Post by boogies »

ArchOversight wrote: post #19
boogies wrote: post #2

Probably a crazy unpopular opinion, but I kind of agree with the Hyperbola (GNU / formerly Linux-libre, in future using a fork of the OpenBSD kernel https://itsfoss.com/hyperbola-linux-bsd/ ) devs that Rust in Linux is not necessarily a good thing, for the reasons they mentioned when they announced they were switching kernels ( https://www.hyperbola.info/news/announcing-hyperbolabsd-road... ) (Edit: and the LLVM depe…

Once again the GPL camp takes and relicenses a project so that further improvements they make can't be used by the original authors. Shame really.

They can be used by the original authors, if the original authors stop intentionally licensing their code so weakly that anyone can make changes that no one else can even see.
Post reply on HN