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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux