1. 15
  1.  

  2. 3

    The more I read the article and its surrounding comments, the more I get the feeling the people involved are better of not integrating rust into the C/Assembly monstrosity called production kernel, for the mess we call hardware, and rather invest their precious time in new kernels that eventually take over linux. Because if they’re fine maintaining their giant C code base and are sure they’re getting enough fresh workforce, why not let them do that. I wouldn’t want to switch places with any kernel developer, which I mean respectfully. This will just be an even bigger strain and seems to already awaken the dark side of OSS again, after the last audacity incidents. Speaking as a fan of rust (and no further kernel-dev knowledge!) I’m not even sure it’ll be that of a huge gain of security or maintanability. The code base it has to integrate in is based around over 30 years of C code and hardware that was written with a c driver in mind, something completely different in terms of its memory model than what rust wants to be.

    1. 3

      I’ve did some professional kernel&embedded work in the past, and now I am a respected RESF member, and other than … well … being implemented in C, architecturally speaking Linux kernel is pretty OK, considering the nature of the problem, essential complexity, performance requirements and so on.

      One of the important reasons that I left a cozy embedded job at nVidia (and the embbedded space as a whole), was that I was sick and tired working with C, where every little mistake is a catastrophic security issue, and all abstractions have to be built&invoked manually, everything is there to get you, and you have to watch every little line 3 times.

      One could have a debate about monolithic kernels, and so on, but ignoring that - Linux kernel is just a low level imperative code, and is pretty good at that, IMO. And Rust with its ambitions and targets specifically should yield itself to fill exactly that very niche, allowing to build zero-cost abstractions that should just make working and reviewing the code much faster and pleasant.

      I’m not even sure it’ll be that of a huge gain of security or maintanability

      I don’t think it will do much about more sophisticated and complex aspects of it, but I think it will yield itself to be tremendously helpful by eliminating having to pay attention to minor, all too common mistakes, and potentially allow building type-guided APIs to ensure correctness. Relevant meme to illustrate.

      All in all I think the effort is valuable just to try it out, and will pay back to Rust community by giving some focus on otherwise neglected areas. We are already seeing GCC support being worked on, failable-alloc considerations. Definitely not a wasted effort.

      1. 2

        Just some thoughts towards some parts, not really disagreeing:

        Linux kernel is just a low level imperative code, and is pretty good at that

        Well I’d say it works pretty good in production, so you may as well leave it as it is. Even though all the memory hardening and review work may be higher than it could be.

        allowing to build zero-cost abstractions that should just make working and reviewing the code much faster and pleasant

        Yeah but don’t underestimate the burden it takes to build a good rust API around pointer based stuff. See previous attempts at things like wayland etc. Some other part I see problems with is the compile time with more proc macros to build API abstractions with the kernel interface.

        will pay back to Rust community by giving some focus on otherwise neglected areas

        The gcc compiler and especially fallible allocations will certainly improve rust for embedded.