Jarkko Sakkinen
jarkko
It's not that it cannot be done but it will result long-term maintained code that is hard to reverse to opcodes at the CPU core just by looking at the snippet code.
This is exactly the gist of any possible kernel patch review..
I'm not disregard its usefulness in user space code but it could be even counter-productive tool in kernel code.
It's the added cost of time for kernel maintainers that weights here. Most (all) could cope with non async Rust from the perspective of what CPU does when it executes a specific peace of Rust code. Developer productivity is the most insignificant portion of kernel development cycle. I'm 100% sure that async is not existential feature, meaning that any possible feature could not be implemented without it.
#rust #linux #kernel
1
6
4
Write your own damn executor :-) Use it with your async code until you get it because you probably end up fixing it a lot. It can be bad and should probably be switched eventually to a production quality executor but this is fastest learning curve I know and this is how I learned its internals because I don't like reading about programming languages :-)
1
0
1
0
0
1
I'm a bit concerned about code generation but obviously my concerns might not have as much as weight as I think they do now :-) [never mind to get things wrong, that's why I say a lot of stupid things on Internet so that I continue learning]
C or and Rust without async is for me like that if I look at a patch, i.e. just the diff I can get idea the structure of generated assembly code, as long as I know also the CPU architecture and calling convention reasonably well. For me code with async is not as predictable because vast amount of code generation but maybe with more practice and disassembling such changes that radar would improve over time 🙂
I have to say that best learning exercise using Rust was to write an executor. Took like couple of afternoons to get it working and learned how Future, Pin and other traits play in that game. If I had not done the exercise, I would be still hitting my head against the wall on that topic. That and grasping std::marker::PhantomData can get one far with Rust 🙂
0
0
0
@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 :-)
1
0
0
That is probably for a kernel maintainer the best possible to draw bridges than do any possible low-hanging fruit alike random contribution. I wait week or few but proactively keep this idea in my mind.
Thanks for the inspiration!
0
0
0