Jarkko Sakkinen
jarkko
@GossiTheDog I'd generally prefer either Firefox or Chrome, or unbranded versions of them (like Debian's Iceweasel), even if there is zero controversies because obviously it is nearest the upstream where e.g. security fixes land first.
0
0
1
Jarkko Sakkinen
repeated
repeated
Marcin Juszkiewicz 🙃
hrw@society.oftrolls.comLinux 6.10-rc1 got released yesterday. With brand new `mseal()` system call.
So my automation kicked in, posted pull request, I merged, page with system calls table got rebuilt:
https://gpages.juszkiewicz.com.pl/syscalls-table/syscalls.html
0
2
2
@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
Jarkko Sakkinen
jarkko
v6 of #TPM2 #asymmetric #keys patch set: https://lkml.org/lkml/2024/5/28/150
The new version includes also sub-type for ECDSA signing and verification.
#linux #kernel
The new version includes also sub-type for ECDSA signing and verification.
#linux #kernel
0
0
1
@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
@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