• 0 Posts
  • 45 Comments
Joined 2 years ago
cake
Cake day: August 17th, 2023

help-circle


  • I very much dislike Mozilla’s direction over the last decade. They’re introducing user-hostile features that subtly break normal browsing experience, even when disabled[0]. Not like Google is better, but I’m also trying to get away from Mozilla.

    [0] On Firefox Mobile, there’s a “feature” which makes the address bar auto-complete domains of companies paying Mozilla. I noticed this with Netflix - I never visit, but when I start writing a URL with n, roughly every 10th time Netflix was suggested. You can disable this feature, but this doesn’t actually disable it. The address bar no longer auto-completes with Netflix, instead it just doesn’t autocomplete! So 9/10 times I can write n and press Enter, but 1/10 times I press n and search for the letter n.

    Mozilla doesn’t care whether they break features, as long as they can make more money. I strongly dislike this approach by the supposedly “good” browser manufacturer.





  • 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?



  • 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!





  • 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.