Comment by yencabulator
10 months ago
And it sounds like you read just one side of the story, with no background in Linux kernel internals. This is about how C APIs are typically inherently unsafe, Rust people wanting to build safe(r) abstractions on top, and a question of who is responsible for changing what code when it's time to refactor the underlying C API. And yes, marcan is being overly dramatic, though he is not alone in that.
I do not claim a background in Linux kernel internals. I'm a human who has seen teams miscommunicate in the past, and see it now. I'm not sure what I said that drew hostility.
It sounds like you agree with me though. The Linux team needs to clearly define the expectation they have for code maintenance from the team trying to upstream Rust code (edit) and the Asahi team needs to acknowledge how/if they can meet those expectations.
Well, stop accusing people who's work you don't know of being wishy-washy.
The challenge is not dictating from high above some criteria; the challenge is discovering the criteria that will let the Linux project continue development as well as can be arranged. This is why you'll hear Linus say it's a learning experience, and not just make proclamation of how things shall be (at this stage).
I don't think it's reasonable to read my original comment as an "accusation". I said "it sounds like" as part of a casual conversation about the subject. There was no hostility in my comment.
Would you say that the Asahi team wasn't receptive to the pace at which the needed criteria were being developed?
My point is that between these two groups there seems to be a misunderstanding of expectations. And being the upstream org, and not having read every mailing list thread, I would expect the kernel team to have built a framework for accepting this kind of code. Or a framework for building the framework.
4 replies →