Lars Wirzenius
liw@toot.liw.fi
It's really difficult to agree on solutions, or end goals, or the way to get to them, if one can't even agree on the problems.
This may be a subtoot about Rust in the Linux kernel, or it may be unrelated.
1
0
0
@jarkko have you seen the kind of abuse the devs get? unfortunately it's not pretty https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@gmail.com/
1
0
0
Jarkko Sakkinen
jarkkoTake almost any subsystem, like PCI documentation for instance, and it should be clear that this blocks bi-directional communication: https://docs.kernel.org/rust/
1
0
0
@jarkko maybe check the timestamped video for a sample. for some people, it seems to be more important to get to yell YOU CANNOT FORCE US TO USE RUST, than it is to listen to what is even being attempted or asked for. more important to escalate and increase the divide than to try to find mutually beneficial ways forward
1
0
0
Integrate documentation updates as part of the patch review process. Not a big deal.
Obviously toxic behavior is bad but also reach and approachability of Rust-for-Linux is not in a great state, and this only because documentation has not been a priority so far. People tend to evade things that they don't know what they are.
It would not be very educated to think that the problem is only on kernel developers who are not contributing to Rust-for-Linux (which is not same that saying that any bully behavior would be acceptable in any possible situation).
1
0
0
1
0
0
https://docs.kernel.org/rust/coding-guidelines.html
For a regular kernel developer or maintainer the first question is obviously how do I apply kernel doc comments here? The page neither explicitly state whether RST or MD is used for the function header comments. With the current information I'd be already lost before writing a single line of code because the documentation is not explicit in conventions.
1
0
0
@jarkko I think we are completely talking past each other about completely different things. Sorry.
1
0
1
[and even if documentation sucks that does not give right to be asshole]
1
0
1
I have no idea why they removed this great series but it was with the topic "Rustproofing Linux". I only recently bumped into them. It was kind of material that would be nice if NCC would contribute it to the kernel documentation. At least for me cleared up bunch of things that I did not get before.
1
0
1
@jarkko seems to be available on the internet archive, will read, thanks for the tip! https://web.archive.org/web/20240822111017/https://research.nccgroup.com/2023/02/16/rustproofing-linux-part-4-4-shared-memory/
last night i ended up watching the full video of the presentation, and sadly it seemed like the relevant C driver folks are not keen on documenting things either. when the rust devs were asking questions to check whether they had understood details correctly, they were repeatedly told they're wrong, with seemingly no interest in improving the understandability https://mastodon.social/@anotherwalther/113050960001374205
1
0
1
Jarkko Sakkinen
jarkkoIt could be also just my own beliefs but I got impression from some Rust posts sometimes that some people think that there would be some kind of large-scale plan to reimplement Linux with Rust. It might be something that Microsoft and Google would like to happen but otherwise such plan does not exist.
There is neither a plan to not do it. The point is that we look at best for Linux maybe few weeks ahead and the overall result is distributed consensus.
That leads to the conclusion that only way to increase Rust adaptation is to make it lower hanging fruit than it is today. Documentation is a great starting point.
1
0
0
1
0
0
Even outside Rust circles some people give up on kernel development because a major feature patch set can take about the same time to upstream going to through various forms and sizes, as Rust has been available.
0
0
0