Conversation
Jarkko Sakkinen
jarkko
For #kernel it is critical to have gccrs features in par with rustc.
Up until that rust-on-linux is a toy feature at most.
IMHO, the language spec should be an ISO/IEC standard and not a "Github standard". This way two toolchains would be easier to keep in par.
With the current infrastructure Rust should be really renamed as MS Rust ;-) It is a semi open-source project controlled by MS infrastructure
and LLVM toolchain. ISO standard would fix a lot here.
#rustlang #rust
Up until that rust-on-linux is a toy feature at most.
IMHO, the language spec should be an ISO/IEC standard and not a "Github standard". This way two toolchains would be easier to keep in par.
With the current infrastructure Rust should be really renamed as MS Rust ;-) It is a semi open-source project controlled by MS infrastructure
and LLVM toolchain. ISO standard would fix a lot here.
#rustlang #rust
3
3
4
Just one example of "semi-opensource": You have to create an account to a proprietary service (Github) to report a compiler bug. This means that if you don't want to use Github, then you are excluded from the project, including reporting legit bugs.
If language standard was in place, only rustc would be concerned by the proprietary development process but you would have a choice of not participating it and still be involved e.g. as part of ISO process or by contributing to gccrs.
If language standard was in place, only rustc would be concerned by the proprietary development process but you would have a choice of not participating it and still be involved e.g. as part of ISO process or by contributing to gccrs.
0
0
1
matzipan
matzipan@hachyderm.io@jarkko I used to be of the same opinion about standardization until this article: https://blog.m-ou.se/rust-standard/
1
0
0
@matzipan Sorry, but I think I pass without reading :-) And more widely than kernel I don't really care of this issue, nor do I care what Rust community does or doesn't do. I'm not part of that of that community. I'm looking Rust as a tool that we are using.
I just listed stuff that I think is absolutely required for defconfig maturity. It is pretty hard to imagine that Rust would be ever widely accepted in kernel, if gccrs does not reach rustc, and that cross-compatibility would be maintained somehow.
And Github requires an account to a proprietary service, which makes the whole process implementation a closed and proprietary.
I just listed stuff that I think is absolutely required for defconfig maturity. It is pretty hard to imagine that Rust would be ever widely accepted in kernel, if gccrs does not reach rustc, and that cross-compatibility would be maintained somehow.
And Github requires an account to a proprietary service, which makes the whole process implementation a closed and proprietary.
1
0
0
matzipan
matzipan@hachyderm.io@jarkko up to you what you want to do. But you're confusing between specification and standard.
1
0
0
@raggi Well, nothing is perfect but at least it is company-agnostic entity with representative from each country. Github is a single vendor proprietary entity. And not being even submit a bug without having to a create an account to a proprietary service is a problem. Finally, it would be weird if any kernel's arch defconfig would acquire Rust feature before both gccrs and rustc can compile the kernel. I don't mind even Github or ISO, as long as there is a way to keep toolchains in sync that works well.
Right now it does not matter that much as gccrs is still heavily under development but it would be good to consider this topic early on. Last time I check gccrs it was still lacking e.g. inline assembly...
Right now it does not matter that much as gccrs is still heavily under development but it would be good to consider this topic early on. Last time I check gccrs it was still lacking e.g. inline assembly...
1
0
0
@raggi E.g. C++ has a mailing list to submit proposals for the standard and associated discussion: https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals. And a full standard associated site. It s also easy to backtrack language related discussions thanks to the mailing list archives.
So it would be up to Rust Foundation in the end how open they want the process be.
I don't mind rustc being in Github as it would be just an implementation of a language standard.
So it would be up to Rust Foundation in the end how open they want the process be.
I don't mind rustc being in Github as it would be just an implementation of a language standard.
0
0
0
@raggi I'm just trying to make sense of what is needed to even theoretically get something made with Rust to a defconfig, I don't specifically vote for ISO but the current model seems broken too. Perhaps Rust Foundation could host repositories just for the language standard and make the process email based. That could also work.
0
0
0
@raggi Github has guidelines, it can take a repository down based on its own decision and you cannot report a bug without an account just to name a few things that do not make a Github project just a Git repository. And all Rust projects use features such as issue database. I could agree with that if Rust was using Github as just a git repository but it is really not.
It is just an objectively false claim. I cannot help it tbh.
It is just an objectively false claim. I cannot help it tbh.
0
0
0
@raggi Not necessarily want email based workflow, it is just one vendor-neutral example. E.g. Rust Foundation itself just detach only language spec project from Github, and then host its own repositories and issue database, and have a method of submitting changes for it.
1
0
0
@raggi In the end of the day I don't mind how 1:1 compatibility with the language spec is maintained as long as it works for rustc and GNU project. If it works for both with Github, then it is not my problem. I'm just consumer for these tools and part of neither community. Still for kernel, gccrs must have enough features to be drop-in replaceable with rustc, at least to compile kernel. In the long-term at least.
0
0
0
@raggi Yeah, please understand that I would love to see some day rust in some arch's defconfig :-) So not claiming that I know things better than e.g. respective language communities but instead am just documenting here my own concerns.
I'm also happy to get things totally wrong :-) I never "defend" any of my opinions at the time...
I'm also happy to get things totally wrong :-) I never "defend" any of my opinions at the time...
0
0
0
tshepang
tshepang@hachyderm.io@jarkko why is it critical to have gccrs have features in par with rustc
1
0
0
tshepang
tshepang@hachyderm.io@jarkko would you not rather have the inconvenience of another toolchain (portability concerns aside), than wait for however long it will take to get gccrs to be ready... rustc is not standing still, and gccrs is far from having enough people to get it anywhere close
1
0
0
tshepang
tshepang@hachyderm.io@jarkko you mentioned gccrs should reach feature parity with rustc before Rust being enabled by default in Linux would be an ok thing
1
0
0
@tshepang Not something that pro-actively waiting for but before that happens Rust is by.practical means blocked from defconfig's. It is then up to those who work on these compilers to find a way to make it happen (such as ISO standard).
2
0
0
@tshepang Ultimately I cannot say anything definitive as it is up to arch subsystem tree maintainers, but I would be less surprised to win in lottery, than see an arch subsystem tree that would require two cross-compilation toolchains to make a build. From that I can pretty much deduce the original claim that feature parity is mandatory for linux-rust to have any long-standing significance in linux kernel.
1
0
0
tshepang
tshepang@hachyderm.io@jarkko you do not like having to have 2 toolchains to compile the kernel, meaning you do not see it as an ok thing
0
0
0
tshepang
tshepang@hachyderm.io@jarkko lack of a specification/standard is far from what stops any alternative Rust implementation (like gccrs) from reaching feature parity with rustc... there is enough tests and documentation to get close enough to the behavior of rustc, before that lack matters more than the effort to get that close
0
0
0