Eww

The answer is disappointingly simple: emotional satisfaction.

For decades, these people have been told that they are incredibly generous towards their allies, and that they get nothing in return. That their allies are abusing their relationships. Of course this is false, but they’ve been told so every day.

Now they get to abuse their “abusers” right back.

Once, my Slack account was deleted due to an error in an automated system, along with everything else, while I was at lunch. That was fun. But not as fun as the 6 months it took until all access was mostly restored.

That sounds really cool, thanks for letting us know!

This may be good advice if your goal is to keep your relationship as long as possible, but that shouldn’t be your goal. It should be to be happy.

Have you ever seen, met or been a teenager?

Cause for 95%, that’s impossible

Just like the ocean is the best body of water for children who want to learn about swimming

And that’s why scoped styles are a godsend!

Global styles were simply always a terrible idea.

I’m not at a computer with the source on it, so if you get to it before me, how many rust drivers are there? How many that would use the rust dma wrapper?

… of course there aren’t many Rust drivers so far, since the project is still young, and it’s evidently still facing hurdles and not really accepted by everyone. But if there’s already a couple of Rust drivers and Rust has explicitly been accepted into the Kernel, we’re already past your “this would make it easier for hypothetical rust drivers that might hypothetically exist in the future”, so why argue such irrelevant points?

More broadly there are times when duplicated c code has been condensed into a library or something and added to the kernel.

And that’s what has been blocked here…

Yes, literally include the wrapper code in every rust driver that needs it then when you push the wrapper on its own you can say “this code is currently duplicated 900 times because there isn’t a rust wrapper” not “this would make it easier for hypothetical rust drivers that might hypothetically exist in the future” and no one will bat an eye!

That is what they are already doing and it’s introducing unnecessary work! There’s nothing about “hypothetical rust drivers”, it’s the case right now.

That’s how you get things added to the kernel!

Weird, how come C drivers don’t have to track these interfaces in their own trees? Why is this the way to get Rust code added to the kernel, but all other code doesn’t have to jump through these hoops?

Linus owes you, nor anybody not signing his paycheck, a goddamed thing.

No, he owes the community to fulfill his role in this community project. He’s not a king or a monarch or whatever you think he is. If he’s not ready to fulfill this role, he should step down as project lead.

but I have enough experience with c, c++ and rust to know that those wrappers don’t need to be in the kernel if the kernel has c bindings.

I think you have a fundamental misunderstanding of the topic.

If I were writing something in rust I could just include the r4l wrapper for the kernels c bindings and everything would work fine. The wrapper doesn’t need to be in the kernel.

We’re talking about device drivers, which are part of the Linux kernel. If you develop these wrappers outside the kernel tree, you’re making the situation even worse, since the kernel suddenly has a new dependency.

This approach was never considered, even by the maintainers that blocked wrappers, because it would be far worse than every other possibility.

Instead the question is: does every driver have to include a copy of the wrapper, or can there be one copy that’s used by all the drivers? And obviously one copy makes far more sense than N different copies.

I’ll skip over the rest of your comment, since it all seems to be built on a broken foundation.

Or I can ask Linus to do his job properly and lead on this issue, whether it’s for or against R4L.

You seem to be under the impression that I’m somehow involved with R4L or Rust, or that I even use Rust. None of these are true. I’m just seeing an example of bad project management, and people like you that keep lying to justify the maintainers decision.

So why can’t rust modules use the c bindings?

They can, if wrappers are written. These wrappers were blocked by a maintainer.

What im building towards is: if r4l isn’t about replacing c code then it doesn’t need to be in the kernel.

Why? It needs to be in the kernel for new code to get written in Rust. Why can it only be in the kernel if the goal is to replace existing code?

r4l people need to have a clear process and understanding of how they expect to accomplish that goal and be open about it.

They do!

There’s no advice to take for working with maintainers who’ll abuse their power to stop a project they don’t like.

Okay so if the point of the rust for Linux project isn’t to replace c code with rust then what is the point?

The purpose is to allow new modules to be written in Rust, not to replace C code. Why are you acting like you don’t know this already?

For the last time, the decision to include Rust has already been made. The “prove him wrong by developing out-of-tree” has already happened.

given the situation, what do you think is the answer to replacing a huge c codebase with rust under the specific conditions of Linux development (open source, overwhelmingly maintained by 9-5 lifers employed by disparate organizations, in use everywhere for everything) when maintainers say they’ll oppose it?

Nobody is trying to replace a huge C codebase.

The project lead OK’d the R4L experiment (which, again, is NOT about replacing C). Why should individual maintainers be able to completely block this outside their own subsystems?

Why lie about something so easy to check? Here’s the maintainer himself saying that the issue isn’t “R4L folks wanting to toss the maintenance headaches over the wall, for someone else to deal with”:

I accept that you don’t want to be involved with Rust in the kernel, which is why we offered to maintain the Rust abstraction layer for the DMA coherent allocator as a separate component (which it would be anyways) ourselves.

Which doesn’t help me a bit. Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this.

The maintainer literally says the issue is that there are two languages. There is no way to convince them, there’s nothing anyone can do.

Which doesn’t help me a bit. Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this.

The maintainer didn’t say “I worry about the maintainability, please prove that it works outside the tree” (this concern was already discussed when the R4L experiment was officially OK’d). They are explicitly saying they’ll block Rust in the kernel, no matter what.

I don’t know how to better explain this to you.