9 ms·

i don’t want rust in the kernel, because it will make my job as a small device manufacturer even more complicated. it is already super hard / time consuming to

• karmanyaahm 5y ago
  I'm pretty sure it will be totally optional to write drivers in Rust, rather than C.
  • megous 5y ago
    I just really hope this thing will not be a bitch to cross-compile. I'm not interested in building llvm + rust in addition to my 5 or so gcc cross-compilers, especially looking at the cadence of rust releases. So as long as it will be possible to use the system's llvm+rust to build for all 4 CPU archs (at once) I'm currently building my kernels for, I'll probably not be too cranky about rust in the kernel.
    • b20000 5y ago
      what if your driver or user space app is affected by a poorly architected driver which was written in rust? now you need to deal with that rust source code. a true nightmare.
      • dagmx 5y ago
        Why would that be worse than if it was written in C? A rust codebase would be much easier to find the bugs in and refactor accordingly, than in C. Plus it's not like most people are going to dive into driver code without experience in the driver itself. So it's a niche set of folks this would affect, the majority of whom would likely be writing the rust code anyway since they're likely the ones most familiar with the driver aspects.
      • kbenson 5y ago
        People have said the same thing about every language. I'm positive people complained about using C over assembly (people still do for certain things). I ask you to imagine a situation where a kernel is written in assembly, and they decide to start allowing C to be used for drivers. How would you view a change such as that?
        • edgyquant 5y ago
          There’s a huge difference. Rust syntax is a lot more complex than C, while this isn’t true for C v assembly.
          • kbenson 5y ago
            The semantics of C and how to write code that is well defined is much more complex than assembly.
            • formerly_proven 5y ago
              C is easy to read and follow though. Rust has far more syntax and as a language is way beyond the complexity of C.
              • nicoburns 5y ago
                Only if you know C but not Rust. I personally find Rust fairly easy to follow and C a complete nightmare (the details in C are ok, but it's really hard to see the forest for the trees).
                • edgyquant 5y ago
                  I know C and can get by in Rust and I disagree that rust is easier to follow. C is a simple language, the complexity comes from large systems, while Rust is just not.
                  • 5y ago
    • duped 5y ago
      Cross compiling with Rust is actually not that bad.
    • floatboth 5y ago
      LLVM is always inherently a "cross-compiler". In fact having to have "5 or so compilers" is just GCC being stupid.
      • megous 5y ago
        Good. :)
    • kelnos 5y ago
      Cross-compilation with Rust is fairly trivial; it's just a matter of "rustup target add some-host-triple". GCC's cross-compilation story is indeed a nightmare. I expect if you have to use the GCC Rust backend (after it's ready) for arches rustc/LLVM don't support, you'll have that pain, but I expect it will just be a matter of adding an "--enable-language rust" to the GCC configure script run, similar to adding C++, ObjC, etc. to a GCC build. So the cross-compiler build will take longer, but won't involve extra steps or infrastructure.
      • megous 5y ago
        Binutils/gcc cross-compiler can be built rather quickly, once you know the right configure flags for each. Then it's just make && make install. You can speed the buil considerably by building with -g0 and not doing a bootrstrap or building needless targets. Then you have a cross-compiler in some --prefix that you can point the kernel build system to via some environment variables and you're done. It's a well known process. It's basically built just like any other dependency and doesn't take much time. Hardly a nightmare. If it would be possible to just add rust to the list of gcc languages, that would indeed be very easy.
    • lambda 5y ago
      Cross compilation is actually much easier with Rust than it is with gcc. Every Rust compiler is a cross-compiler for all architectures that Rust supports; all you need is the rest of the toolchain like linker and libraries. rustup handles installing the libraries, and as lld (the LLVM linker) adds support for more platforms it can also be used as a cross linker, rather than a linker per target as in the older toolchains.
• simias 5y ago
  I understand your concern and I would definitely feel the same if some language I wasn't familiar with was suddenly introduced in the kernel. But at the same time as a big Rust enthusiast I think it's really a good idea in the long run: C is going nowhere but it's really dated, design-wise. When you've tasted the sweet nectar of type inference, strong typing, union types and of course the safety of the borrow checker, returning to C feels like banging rocks together. The main drawback of Rust here I think is the longer compile times (I dread to imagine how long a fully Rustified kernel would take to build) and a generally more complex, but also more expressive language. More generally I trust the kernel maintainers not to succumb to the hype and overdo it. People who still exchange patchsets over mailing lists are probably unlikely to be blinded by shiny things.
  • viraptor 5y ago
    > The main drawback of Rust here I think is the longer compile times The time scales with the compiled unit size. If you're compiling drivers/modules, they're going to be fairly small and not much slower than C.
  • b20000 5y ago
    the point is that you still need to know what you are doing. rust won’t change that. C is everywhere, and that is not going to change anytime soon. your time is better spent understanding more of the kernel instead of learning another tool set. one of the biggest hurdles for me was the DTB declarative language. that was the most stupid idea ever to invent that and i lost 100s of hours trying to get my DTB files right for my hardware. so you can understand i don’t want more hipster shit to deal with.
    • throwamon 5y ago
      > your time is better spent understanding more of the kernel instead of learning another tool set No matter your skill level, that won't stop you from committing memory-safety mistakes that may lurk for years until they suddenly result in a catastrophic failure. Evidence for that is abundant.
    • dagmx 5y ago
• Barrin92 5y ago
  no offense but aren't security concerns just as pressing in the world small manufacturers, embedded etc.. given that those kinds of devices are nowadays part of pretty vital infrastructure? the lack of memory safe languages is probably the nr. 1 contributor to critical bugs in software and regardless of what we're working on we ought to learn new languages if they help to improve software quality.
  • ggrrhh_ta 5y ago
    I don't believe that the change to rust (and I like rust a a lot) will lead to a measurably more secure kernel in the long term, although it will mean that maintaining the kernel will require knowledge of Rust in addition to C (and some flavors of assembly, occasionally). On top of that, the Rust that can be compiled into the kernel will be a subset, or its compilation will be tuned [idiomatic and safe allocation of memory within the stack, efficient Rust/C interoperability with dynamically allocated memory, in a Rust-safe way, etc.]. Let me explain why I think that: In the short term, having more eyes looking at and re-implementing the scaffolding for drivers and the drivers themselves will certainly lead to a very positive outcome - many potential bugs (of which, most of them will not really be exploitable, but some will) will be uncovered which couldn't have been introduced with safe Rust. However, at some point, the coolness factor will drop, drivers will become fossilized, a larger developer base that has to maintain older Rust drivers might cut corners, use more unsafe features, misunderstand/misremember the nuances of this or that, and what was once exciting is now tedious. Maybe not, maybe Rust will slowly replace the whole kernel, however, at the current stage at which Linux is, I find it unlikely (but possible).
    • nicoburns 5y ago
      > a larger developer base that has to maintain older Rust drivers might cut corners, use more unsafe features, misunderstand/misremember the nuances of this or that, and what was once exciting is now tedious. The great thing about Rust is that it makes it much harder to cut corners, and much more obvious when someone does (making it easier to pick up at review stage). Invariants can be built into APIs in a way that simply can't be done in C.
    • 5y ago
• kelnos 5y ago
  That just sounds like "I don't want progress because it will mean I have to learn new things and I don't want more work for myself". Well... tough luck? Regardless, if you want to keep using C to write your Linux drivers, the new Rust support does not change that.
  • mkipper 5y ago
    If you're a device manufacturer trying to manage common code for a variety of hardware platforms with subtle differences in toolchains / kernels, dealing with all that complexity can be pretty tough. If Rust drivers start popping up in the kernel, you now need to start dealing with twice as many toolchains and twice as much complexity. One of those toolchains is used to build the bootloader, kernel and majority of userspace software for the devices. The other toolchain is used to build an I2C temperature sensor driver that was rewritten in Rust so someone could put Rust driver experience on their resume. Dismissing this and saying "suck it up, this is the price of progress" is fine. But it doesn't change the fact that this could be a giant PITA for people making devices and developing the BSPs for them while providing almost no value. I'm not trying to argue that appeasing this group is important enough to totally reject Rust from the kernel, but as a maintainer, making life difficult for a huge number of kernel users is probably something you'd like to avoid. I think a lot of this will come down to how Rust patches are reviewed and accepted. If Amazon or Facebook want to upstream some new Rust driver they wrote for their own hardware, there's probably no negative impact to anyone by merging it. But I'd expect maintainers will be very hesitant to accept patches that touch existing drivers. I guess time will tell.
    • b20000 5y ago
      amazon or facebook can afford to pay lots of developers to deal with this. i cannot, and if they force their rust code onto the community, it will close the door for lots of smaller device manufacturers including myself. and that is the main issue. linux does not exist to entertain the interests of those with more money.
  • raxxorrax 5y ago
    Reading up on the Rust spec and concepts is fairly trivial compared to letting a lot of devices and their drivers interface each other. I don't think Rust inclusion will change that however. Time will tell, but your response is rather childish.
• lambda 5y ago
  Adding Rust doesn't make it harder to do any of this. When you build a custom driver, you could choose to develop it in C or in Rust. It gives you the choice, and many of us find it easier to build in Rust than in C; but even if you prefer C, you will still have that choice. Most of "tuning the kernel for specific applications" consists of making changes to the kernel config or compiler settings. Rust won't change the kernel config system, and compiler settings for Rust are quite similar to those for C, as Rust uses LLVM as its backend, and LLVM is used by Clang which goes to a lot of effort to provide a mostly GCC compatible interface. > in the end, you still need to understand what you are doing, and rust is not going to change that. If think you understand what you are doing in C, you probably don't. C is a fantastically difficult language to write correct code in at scale; even the best developers make simple mistakes all the time. I understand the frustration at seeing something else you might have to learn and deal with that might make things a bit trickier during a transition, but that's pretty much the nature of keeping up with any kind of ongoing development process. It's not like the Linux kernel sprang fully formed out of Linus's head on day one and it's just been a matter of adding drivers and making small incremental fixes. There are all kinds of changes that require you to change and adapt, like the removal of the Big Kernel Lock, or pretty much any internal API work, and yeah there can be work to keep up, but that doesn't mean you should hold back progress.