@raggi Hmm…
So one option would be to create Documents/rust/async-guidelines.rs and document pre-existing usage patterns in Linux. I think it would be better try not to over-engineer the document. One example would documenting async itself. It is probably the best idea to keep it compact and punctual.
All you need to do then is just modifying the existing guidelines and adding sometimes completely new guidelines based on the patches.
Now, if I send a Rust patch with some async code, it will now be less likely to be against maintainers expectations. That results less noise in the mailing list, and patches landing more quickly. Or that’s I’d see it.
Way more important benefit would be that async would be “existentially” sealed to the kernel ecosystem early on.
I think this just like basic governance and risk management, not IMHO a big deal :-)
PolkaVM is based on RVI20U64, which is a RISC-V profile lacking machine (M) and supervisor (S). The ALU of RVI20U64 has 47 opcodes in total.
I also noted FENCE and FENCE.I are in the profile. Are they useful for a single core CPU package?
Does this architecture have pmpcfg*
registers? It would not make any possible sense to me so I’m only sanity checking here.
Here's a fascinating look at the first IBM PC 5150, from my friend David who wrote the training documentation.
I had missed that AWS discussed how they use #eBPF to implement network policies, optimize TCP performance, and reduce Lambda function cold starts.
Recording: https://youtu.be/pVJHljuz1F0
Microsoft breaking a bunch of dual-boot systems by revoking insecure versions of grub during a standard Windows update is, uh, not great and was not supposed to happen, but it's worth mentioning that systems broken by this were running known insecure bootloaders and anyone running a distro that's actually on top of security updates was unaffected
(Edit to add: I wasn't terribly clear here. It's not the user's fault if their distro fails to deal with this, it's the distro's)