Re: On community influencing (was Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.)

33KK
2025-02-13T19:24:52Z

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.