Message-ID: <6e3e26c7-002a-49c6-a3a8-1cc1b8941f57@kkx.one>
Date: Thu, 13 Feb 2025 20:22:52 +0100
From: 33KK <hello@....one>
To: torvalds@...ux-foundation.org
Cc: a.hindborg@...nel.org, abdiel.janulgue@...il.com, airlied@...il.com,
 airlied@...hat.com, alex.gaynor@...il.com, aliceryhl@...gle.com,
 benno.lossin@...ton.me, bjorn3_gh@...tonmail.com, boqun.feng@...il.com,
 dakr@...nel.org, daniel.almeida@...labora.com,
 dri-devel@...ts.freedesktop.org, gary@...yguo.net,
 gregkh@...uxfoundation.org, hch@....de, iommu@...ts.linux.dev,
 jgg@...dia.com, kernel@...entinobst.de, linux-kernel@...r.kernel.org,
 m.szyprowski@...sung.com, marcan@...can.st, miguel.ojeda.sandonis@...il.com,
 ojeda@...nel.org, phasta@...nel.org, robin.murphy@....com,
 rust-for-linux@...r.kernel.org, tmgross@...ch.edu
Subject: Re: On community influencing (was Re: [PATCH v8 2/2] rust: add dma
 coherent allocator abstraction.)

Honestly, how about you accept the fact that maybe the problem is you?

You're not doing any good by just scolding Hector for "social media 
brigading"
and not addressing the core issue, especially considering that LKML 
drama always
ends up on social media and on reaction content farms anyway, without the
"brigading", and Hector wasn't the one who started the drama.

You can't expect people to just keep going on and on in circular 
conversations
on the mailing list with somebody who isn't even engaging in good faith. 
These
conversations are about as technical as high school bullying, with you 
being the
teacher who punishes the one who tried to speak out, because they didn't 
want to
deal with figuring out who is right or wrong, and the victim is trying their
best to work out a solution for an unsolvable problem, since there's no 
solution
that the other side would accept.

Obviously, the people involved are tired of having this shit show happen 
again and
again and of course they will end up going to vent on social media, 
break down,
or leave, since they're not heard on the mailing list, and their mental 
health,
time and energy is clearly not respected by any of the adults present in the
room, judging by the complete inaction on the part of Linux's leadership.

You can't just pretend that multiple people leaving because of this is not a
problem. You can't just have people burn their time, energy and mental 
health on
pointless "discussions" and end up burning out, breaking down or leaving 
instead
of getting anything done. You can't just keep having your maintainers 
break down
one after another. This is not normal. This is not healthy. The process 
isn't
"working".

Just letting these "discussions" keep playing out like this is terrible
leadership, and is clearly not working well for mental health of people 
trying
to get involved with Linux.

You either want the R4L project to succeed and have new maintainers want 
to get
involved with the project, and you tell the hostile C maintainers to 
shut up and
cope with it, or you want the R4L project to fail and constantly have these
pointless "discussions" which boil down to some out of touch maintainer 
bullying
someone about something that should've been resolved long ago.

And as far as the *barely* technical arguments in the thread go:

The code is clearly exactly where it should be, in rust/kernel/dma, 
where else
is this supposed to go? Duplicating the bindings in multiple drivers 
would just
make the situation much worse, since now you have to worry about breaking
multiple copies of the bindings. R4L also proposed that they will 
maintain the
bindings.

Is the minor inconvenience of another maintainer having to review breaking
changes to DMA interfaces or some similar process to prevent build breakages
such a big deal compared to the pretty significant benefits Rust 
provides? The
Rust-based drivers were developed very quickly and ended up being way 
extremely
stable with relatively little effort compared to writing the same driver 
in C.

I think the benefits are pretty clear, if you can write a driver without
spending most of the time barely managing to tracking memory ownership 
in your
head, making sure you're not misusing underdocumented kernel APIs, etc.
obviously you're going to be significantly more productive, and it's 
also easier
for a new maintainer to get involved, since it's harder to break something.
Also, when writing safe bindings you have to double-check the safety of 
the API,
which helps to notice unsoundness in the C interface itself.

 > The only reason Linux managed to survive so long is by not having 
internal
 > boundaries

The actual reason Linux managed to survive so long is because of people 
working
together. Nobody understands the entirety of the kernel source, 
maintenance of
subsystems is split between different people that work together. What 
Christoph
is doing here, is pretty much opposite of that. He is actively trying to 
prevent
R4L from writing bindings to DMA, which are crucial to the project. 
Effectively
saying that the project should just go away entirely.

Christoph pretty clearly has no valid argument here.


NOTE: I am not affiliated in any way with R4L or Linux maintainers, I'm 
just a
Linux user watching this shitshow unfold, and am very disappointed about how
it's being handled.

Powered by blists - more mailing lists