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

141–150 of 365 posts

Re: Supporting Linux kernel development in Rust

#141

Post by ghostwriter »

dang wrote: post #127
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…

Please don't be repetitive in HN comments, though. Repetition is the enemy of curiosity and curiosity is the core value here. https://news.ycombinator.com/newsguidelines.html

What would be the proper way of informing those who are interested in the topic about available alternatives? I assume not everyone follows the same topics and there may be people who see the presented information and the relevant references for the first time.

Re: Supporting Linux kernel development in Rust

#142

Post by rickbutton »

dnautics wrote: post #139
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.

Can you give an example of a non-copyleft open source product where the major improvement is proprietary?

nginx

Re: Supporting Linux kernel development in Rust

#143

Post by axaxs »

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 don't see how, personally. There are tons of thriving open source non-copyleft projects. And there are tons of GPL violators who go on business as usual. I think perhaps copyleft licenses are overattributed to the success of such projects.

Re: Supporting Linux kernel development in Rust

#144

Post by shock »

dang wrote: post #127
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…

Please don't be repetitive in HN comments, though. Repetition is the enemy of curiosity and curiosity is the core value here. https://news.ycombinator.com/newsguidelines.html

> Repetition is the enemy of curiosity

I haven't found a source for that, but I don't believe it to be true and I'm curious why you do.

I haven't seen the previous comments of the OP so for me this comment was useful.

Re: Supporting Linux kernel development in Rust

#146

Post by jasonhansel »

axaxs wrote: post #143
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 don't see how, personally. There are tons of thriving open source non-copyleft projects. And there are tons of GPL violators who go on business as usual. I think perhaps copyleft licenses are overattributed to the success of such projects.

Most of the thriving non-GPL OSS projects are supported and funded by large corporate sponsors--not by communities or foundations (e.g. React.js by Facebook, Blink by Chrome).

Furthermore, many non-GPL OSS projects have eventually gone proprietary (e.g. MongoDB's switch from AGPL to SSPL).

Re: Supporting Linux kernel development in Rust

#147

Post by pvg »

ghostwriter wrote: post #141
dang wrote: post #127

Earlier quoted context omitted.

Please don't be repetitive in HN comments, though. Repetition is the enemy of curiosity and curiosity is the core value here. https://news.ycombinator.com/newsguidelines.html

What would be the proper way of informing those who are interested in the topic about available alternatives? I assume not everyone follows the same topics and there may be people who see the presented information and the relevant references for the first time.

You know the sort of person who comments 'Just install Linux' in every thread about more or less any kind of computer problem? You don't want to be that sort of person. If you're starting your comments with 'I'm not going to stop telling you to install Linux', it's probably a good time to check if you're not turning into the sort of person who's always telling you to install Linux.

Re: Supporting Linux kernel development in Rust

#148

Post by bsder »

einpoklum wrote: post #126
bsder wrote: post #112

Earlier quoted context omitted.

> So the natural follow-up question to that concern, it seems to me, would be whether there's something in the existing C/GCC toolchain (or around it) that can resolve the raised concerns without adopting a whole new toolchain (Rust/LLVM) The answer to this question appears to be: no. Memory errors sit somewhere around 2/3 to 3/4 of errors irrespective of codebase when C is involved (this has been consistent in thing…

> C++ hasn't seemed to have changed that, either. C++ is not like C. Putting some C++ objects in a C codebase would, indeed, not change it much, but if you write in modern C++, some memory errors will literally disappear, and some become less likely. Caveat: This is based on language mechanics, standard library facilities and recommended idioms; of course people can write unsafe C++ if they want to.

> of course people can write unsafe C++ if they want to.

The problem is knowing the safe subset of the language requires continuous study and deep understanding. It also has changed with time.

I used to have a bookshelf in order to understand C++. I suspect that has not changed.

I do not need a bookshelf to understand the "safe" subset of Rust.

Re: Supporting Linux kernel development in Rust

#149

Post by geofft »

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.

There was a talk right after ours about LTO! I only half paid attention to it because I was catching up on the chat, but it sounds like Google is doing kernel LTO in prod for their internal systems (and maybe also for Android and CrOS?):

https://linuxplumbersconf.org/event/7/contributions/798/ (slide link at the bottom)

https://youtu.be/FFjV9f_Ub9o?t=3844

Re: Supporting Linux kernel development in Rust

#150

Post by kevincox »

dnautics wrote: post #145
rickbutton wrote: post #142

Earlier quoted context omitted.

nginx

Sorry, I wasn't aware. What's the major improvement?

https://www.nginx.com/products/nginx/

Although this is probably not the best example because this is sold by the company that largely funds the open source project. Although that is a big conflict of interest.

Post reply on HN