Yes, it was. If he had a professional concern about kernel/rust consuming kernel/dma directly, due to that causing blocking issues with kernel/dma- that is by definition a technical concern.
You're wrong.
This perfectly illustrates the pig-wrestling problem. You're arguing that *people not behaving as expected* in accordance with a policy designed to prevent blocking is a "technical" problem. There's nothing technical about it. The prior version works, the intended version works, and something else is permitted to not work because it is dependent, not the other way around. All technology performs as expected. It's a political problem, because you fear that some people won't, and some people may indeed not, follow the governing policy. And people are not technology.
There is an exception to things that break Rust, in that they are allowed- but must be resolved before they reach Linus, and therefor, before the changes can be released.
Do you get the difference?
Yes. Do you? Did you actually read the 'for instance' example? Of course you didn't.
"In stage 1, all fallout from block layer changes fall upon Andreas and group to fix. Under no circumstance will changes from other contributors be held up, or contributors be held accountable, for breakages of the block rust code. Should contributors wish to sort out these issues themselves, then they are of course free to do so, but it won't be something that gatekeeps other changes."
The difference is that the Rust maintainers are expected to resolve the breakage before it reaches Linus, not the other way around. For someone throwing the "claim bred from ignorance" allegation, or better yet the "dipshit" label, you're doing your best to personally exemplify the behaviors.
There's a reason Miguel Ojeda said: "It only affects those that maintain APIs that are needed by a Rust user, not every single developer.", in response to: "So as of now, as a Linux developer or maintainer you must deal with Rust if you want to or not."
Indeed. It's right there in the document - "The intention is to facilitate friendly adoption of Rust in a subsystem without introducing a burden to existing maintainers who may be working on urgent fixes for the C side." Unfriendly changes that are not urgent -- breaking things without adequate justification -- is something that you must deal with if you want to or not. But apparently "don't be an arbitrary asshole" is too much of a burden for Hellwig, and for you, from all appearances here, to bear.
That's some amusing self-importance you've got there, cheerleader.
Ah, yes, the toxic stench that the kernel development community is renowned for has now completely filled the room. The cheerleaders mean nothing, which is why you so fear and resent any publicity that draws attention to the (suddenly former) behavior of an obstructionist ass.
Amusing.