Jarkko Sakkinen
Posts
4507Following
316Followers
477OpenPGP: 3AB05486C7752FE1
@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
@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 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 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 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 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 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
@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
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
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
2
4
The most motivating situation is when you get to work on something you have zero clue about before and there is a real schedule to bring enough pressure to bring movement. Actually sometimes you can move faster than someone with deep domain expertise because you don't waste time as much considering various options...
0
0
0
Jarkko Sakkinen
jarkko
Edited 1 year ago
For this worktree is useful:
git worktree add ~/work/linux-tpmdd-master master
When you have find a bug while working on feature branch and want to quickly do a fix without too much context switch…
Then later:
git worktree remove linux-tpmdd-master
Jarkko Sakkinen
jarkko
Edited 1 year ago
Have a few possible job options post September so looking quite good. Obviously nothing is closed given the 4 month window but I think it was good idea to knock some doors now to rise awareness.
I guess my priority when picking a job is to get to do something out of sec space, but otherwise as long as it is kernel, all works for me, because everything in that space is (still) interesting.
My first touch of Rust in kernel is not to write code myself but help to get existing ASN.1 code integrated with ASN1_RUST flag. I think learning testing/QA process is the first thing focus in any area of kernel, not writing code. Once you have edit-compile-run in place all comes so much easier...
I guess my priority when picking a job is to get to do something out of sec space, but otherwise as long as it is kernel, all works for me, because everything in that space is (still) interesting.
My first touch of Rust in kernel is not to write code myself but help to get existing ASN.1 code integrated with ASN1_RUST flag. I think learning testing/QA process is the first thing focus in any area of kernel, not writing code. Once you have edit-compile-run in place all comes so much easier...
1
0
3