Conversation
Jarkko Sakkinen
jarkko
Edited 1 month ago
So in principle Linux needs to build fully:
1. In GCC
2. In LLVM
This because there is need to be agile and robust with toolchains and it is higher priority than language support.
And the existing problem with Rust is that a kernel compiles either with:
1. In GCC + LLVM
2. In LLVM
This blocks Rust features from defconfigs, which simply mean that they cannot turned by default on.
Fixing this problem is more important than fixing any other possible problem with Rust because it is environmental constraint.
This is exactly why gccrs is important and it is good to see substantial progress being made:
https://lwn.net/Articles/991199/
The progress in gccrs factor over any Rust code in kernel in my opinion because it enables the *production value* for it.
PS. Just wanted to point out the actual issue because I did not spot anything at all from Plumbers :-) Weird because this is something that actually matters, not the stuff how people feel about programming language X.
#rust #rustlang #linux #kernel
1. In GCC
2. In LLVM
This because there is need to be agile and robust with toolchains and it is higher priority than language support.
And the existing problem with Rust is that a kernel compiles either with:
1. In GCC + LLVM
2. In LLVM
This blocks Rust features from defconfigs, which simply mean that they cannot turned by default on.
Fixing this problem is more important than fixing any other possible problem with Rust because it is environmental constraint.
This is exactly why gccrs is important and it is good to see substantial progress being made:
https://lwn.net/Articles/991199/
The progress in gccrs factor over any Rust code in kernel in my opinion because it enables the *production value* for it.
PS. Just wanted to point out the actual issue because I did not spot anything at all from Plumbers :-) Weird because this is something that actually matters, not the stuff how people feel about programming language X.
#rust #rustlang #linux #kernel
1
7
7
@jarkko as was pointed elsewhere, for 2 decades Linux had no issue at all supporting only one toolchain, and sometimes only a limited subset of versions of it(which distros picked).
Yes, the gccrs works is (very) important, but I don't see why it should be a blocker for anything.
3
0
1
@Aissen Backwards compatibility and zero regressions rule answer to both arguments :-)
GCC was there already long before LLVM was even born. LLVM support has improved over time while making sure that GCC compatibility is not broken.
Zero regressions rule includes compile-time regression but minimum GCC version can be upgraded over time.
Also, GCC is GPL whereas LLVM is not. If Linux compiled only with LLVM we would be dependent on corporation good will. Open governance matters too.
GCC was there already long before LLVM was even born. LLVM support has improved over time while making sure that GCC compatibility is not broken.
Zero regressions rule includes compile-time regression but minimum GCC version can be upgraded over time.
Also, GCC is GPL whereas LLVM is not. If Linux compiled only with LLVM we would be dependent on corporation good will. Open governance matters too.
0
0
0
Jarkko Sakkinen
jarkko
1
0
0
@alerque @Aissen
And remember here the gist was (in my post) that this bottleneck is getting sorted not the opposite (maybe even GCC 15). Would be quite weird if at this point especially any maintainer would make any exceptions to the golden rules we have, which stand both time and corporate pressure amazingly well.
And remember here the gist was (in my post) that this bottleneck is getting sorted not the opposite (maybe even GCC 15). Would be quite weird if at this point especially any maintainer would make any exceptions to the golden rules we have, which stand both time and corporate pressure amazingly well.
1
0
0
1
0
2
1
0
0
2
0
1
Jarkko Sakkinen
jarkko
@Aissen @alerque Yeah, so please denote that I neither strongly agree and/or disagree but I think we all can agree that this will help Rust a lot in kernel, right? :-) I still think that this important.
If it gets to some defconfig w/o this fully realizing this, that's fine.
Also since this is in such good progress perhaps that could be even the reason to enable because GCC will be in-par so soon,
If it gets to some defconfig w/o this fully realizing this, that's fine.
Also since this is in such good progress perhaps that could be even the reason to enable because GCC will be in-par so soon,
1
0
1
@Aissen @alerque Also, and this is just my personal belief: overall for any language having multiple compilers is a hallmark really and makes it more like an ecosystem, and seals it as an established programming language. It has existentially sealed itself. Two compilers can cause sometimes friction but that also governs the decision making process for the language so that any future decisions will be done with more consideration. I.e. better quality decisions with the price of perhaps a bit slower progress.
0
0
0
@Aissen @jarkko I don't know, my guess that it could be sold as "best compiler" for ia64 in it's prime years. One comment at https://lwn.net/Articles/320795/ confirms that, mentioning SGI, and there are more insightful comments.
1
0
3
@kdave @Aissen I don't know if you've dealt with embedded ever but reasons might be simply that you have some weird toolchain in that area and no target for rustc at the point of time. However you are able to convince the embedded company an upgrade their toolchain to a newer GCC. In that case the legit Rust support in GCC might be overall bring the whole Rust ecosystem to a portfolio of devices.
Often people who think that it is just some weird ideological/artificial nonsense to be concerned about the details in toolchains, are people who mostly work in cloud companies or cloud customers :-) I fully get that for Microsoft/Google/Meta/Oracle etc. these issues I'm talking about are artificial. But embedded world... it is a world of unimaginable insanity when it comes to toolchains, and exactly this attention to detail in toolchain robustness has kept Linux a top embedded multitasking operating system for decades already :-)
I.e I'm not worried of your cloud, I'm worried of your coffee maker and shit like that ;-)
Often people who think that it is just some weird ideological/artificial nonsense to be concerned about the details in toolchains, are people who mostly work in cloud companies or cloud customers :-) I fully get that for Microsoft/Google/Meta/Oracle etc. these issues I'm talking about are artificial. But embedded world... it is a world of unimaginable insanity when it comes to toolchains, and exactly this attention to detail in toolchain robustness has kept Linux a top embedded multitasking operating system for decades already :-)
I.e I'm not worried of your cloud, I'm worried of your coffee maker and shit like that ;-)
2
0
0
1
0
2
Jarkko Sakkinen
jarkko
0
0
1