5 ms·

No maintainer is obligated to not break any part of Linux other than the user space API, there are no stable in-kernel APIs

• simonask 11mo ago
  What they mean is that the Linux kernel has a long-standing policy to keep the whole kernel compilable on every commit, so any commit that changes an internal API must also fix up _all_ the places where that internal API is used. While Rust in the kernel was experimental, this rule was relaxed somewhat to avoid introducing a barrier for programmers who didn't know Rust, so their work could proceed unimpeded while the experiment ran. In other words, the Rust code was allowed to be temporarily broken while the Rust maintainers fixed up uses of APIs that were changed in C code.
  • Imustaskforhelp 11mo ago
    So does this mean that the C developers might need to learn Rust or cooperate more with the rust developer team basically?
    • bmicraft 11mo ago
      That's exactly the original question.
    • eru 11mo ago
      I guess in practice you'd want to have Rust installed as part of your local build and test environment. But I don't think you have to learn Rust any more (or any less) than you have to learn Perl or how the config script works. As long as you can detect if/when you break it, you can then either quickly pick up enough to get by (if it's trivial), or you ask around.
      • jacquesm 11mo ago
        The proof of the pudding will be in the eating, the rust community better step up in terms of long term commitment to the code they produce because that is the thing that will keep this code in the kernel. This is just first base.
        • simonask 11mo ago
          No matter how hard you try to paint it as such, Rust is not a tribe. This is such a weird characterization. Rust contributions to the Linux kernel were made by individuals, and are very obviously subject to the exact same expectations as other kernel contributions. Maintainers have responsibilities, not “communities”.
          • estebank 11mo ago
            Not only that, those individuals were already Linux kernel contributors. This is not an amorphous external group forcing their will on Linux, it's Linux itself choosing to use Rust.
    • cogman10 11mo ago
      Depends on the change being made. If they completely replace an API then sure, probably. But for most changes, like adding a param to a function or a struct, they basically have to learn nothing. Rust isn't unlike C either. You can write a lot of it in a pretty C like fashion.
      • FpUser 11mo ago
        >"Rust isn't unlike C either. You can write a lot of it in a pretty C like fashion." I think that with all of the Rust's borrowing rules the statement is very iffy.
        • simonask 11mo ago
          C has a lot of the same borrowing rules, though, with some differences around strict aliasing versus the shared/exclusive difference in Rust. Most of the things people stub their toe on in Rust coming from C are already UB in C.
        • cogman10 11mo ago
          Rust's borrowing rules might force you to make different architecture choices than you would with C. But that's not what I was thinking about. For a given rust function, where you might expect a C programmer to need to interact due to a change in the the C code, most of the lifetime rules will have already been hammered out before the needed updates to the rust code. It's possible, but unlikely, that the C programmer is going to need to significantly change what is being allocated and how.
          • FpUser 11mo ago
            Not talking allocations, more like actual borrowing, aliasing, passing as parameters.
    • weebull 11mo ago
      Learn rust to a level where all cross language implications are understood, which includes all `unsafe` behaviour (...because you're interfacing with C). Yes it does.
• dwattttt 11mo ago
  There is, I understand, an expectation that if you do make breaking changes to kernel APIs, you fix the callers of such APIs. Which has been a point of contention, that if a maintainer doesn't know Rust, how would they fix Rust users of an API? The Rust for Linux folks have offered that they would fix up such changes, at least during the experimental period. I guess what this arrangement looks like long term will be discussed ~now.
  • jacquesm 11mo ago
    Without a very hard commitment that is going to be a huge hurdle to continued adoption, and kernel work is really the one place where rust has an actual place. Everywhere else you are most likely better off using either Go or Java.
    • hollerith 11mo ago
      Aren't large parts of a web browser and a runtime for a programming language also better written in Rust than in Go or Java?
      • jacquesm 11mo ago
        I'd say no, access to a larger pool of programmers is an important ingredient in the decision of what you want to write something in. Netscape pre-dated Java which is why it was written in C/C++ and that is why we have rust in the first place. But today we do have Java which has all of the rust safety guarantees and then some, is insanely performant for network code and has a massive amount of mindshare and available programmers. For Go the situation is a bit less good but if you really need that extra bit of performance (and you almost never really do) then it might be a good choice.
        • hollerith 11mo ago
          All the mainstream browsers do their own low-level graphics rendering (e.g., of text and icons and such). Is Java performant enough to do that?