5 ms·

> Because drivers are inherently system-dependent I'm not sure I agree with this. As someone who does development for prehistoric PPC embedded systems, I get t

> Because drivers are inherently system-dependent I'm not sure I agree with this. As someone who does development for prehistoric PPC embedded systems, I get to take advantage of a lot of drivers that were never really intended for my platform, yet work just fine because they're based on standard busses like PCI and USB. Consider some architecture supported by Linux, but not yet Rust. Now, consider that a vendor might create a driver for their fancy new PCIe network card in Rust with the logic being "well, this card was never intended to be used in anything other than an ARM or x86 system". There's a good chance that if that driver was written in C, it would have worked just fine (albeit not officially supported by the vendor) on that old non-Rust-supported architecture, but now that's not an option. Rust should not be used in the Linux kernel until it supports 100% of the architectures supported by Linux itself.

johnisgood 5y ago
I completely agree. We should not get ahead of ourselves just yet. It seriously should support most if not all of the architectures that Linux itself supports. https://doc.rust-lang.org/nightly/rustc/platform-support.html https://doc.rust-lang.org/nightly/rustc/platform-support.htm... vs. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch?h=v5.16-rc4 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... or https://en.wikipedia.org/wiki/List_of_Linux-supported_computer_architectures https://en.wikipedia.org/wiki/List_of_Linux-supported_comput...
- xxpor 5y ago
  LLVM is the real bottleneck here. I've worked with a platform that would have been easy to build a custom rust for (even if it wasn't officially supported), but was held up by the lack of LLVM support.
  - lambda 5y ago
    Yep. But there are two different active projects for compiling Rust with a GCC backend at the moment (one as a completely new frontend written as part of the GCC codebase, one as a libgccjit backend for the existing Rustc), there's also a Cranelift backend for rustc that you could add new architecture support to, and LLVM does add new targets, it can just take a bit longer to get support into LLVM and they don't keep architectures that are lightly or unmaintained around as long as GCC does. For instance, Tier 3 support for m68k-unknown-linux-gnu was recently stabilized in rustc as a result of m68k support landing in LLVM (https://github.com/rust-lang/rust/blob/master/RELEASES.md#compiler https://github.com/rust-lang/rust/blob/master/RELEASES.md#co...), which has been one of the previous sticking points for Rust packaging on Linux distros, some of which still support m68k architectures.
outworlder 5y ago
Chances are that Rust would also work just fine even if the arch is not officially 'supported', as long as LLVM exists on that platform. Also, this is not going to retroactively affect any drivers, only the ones (potentially) developed from now on. As time passes, Rust support is expected to increase.
kelnos 5y ago
> Rust should not be used in the Linux kernel until it supports 100% of the architectures supported by Linux itself. I don't think that's realistic. If we buy the idea that Rust will allow kernel developers to write more robust, safer, more secure drivers, I think that should override a desire to allow things like driver portability to arches that hardware manufacturers never expected or intended. I would judge that support to be a "nice to have", but it shouldn't block what I consider to be more important concerns (security and robustness). Regardless, the Rust support here is still considered experimental. I would be surprised if any company adopted it for a Linux driver for at least a year or more. That's plenty of time for people to get esoteric platforms supported in LLVM/Rust if they want to. And it also gives more time for the Rust GCC backend to become more mature and usable, and I believe that will give Rust support for every arch that GCC supports (more or less), which should cover your objection. (At any rate, LLVM+Rust does currently support PPC, so your specific argument here isn't relevant.)
- sangnoir 5y ago
  > I would judge that support to be a "nice to have", but it shouldn't block what I consider to be more important concerns (security and robustness). So what happens to users that depend on these archs & drivers - get left behind on the last non-Rust kernel?
  - steveklabnik 5y ago
    The same as any other project that decides it may drop support: either stick on an old version, or work to add support for the platforms you care about. Rust's lack of platform support isn't because it is impossible for Rust to gain support for those platforms, but because users of those platforms haven't added support yet. Obviously that is easier said than done, and I doubt that Linux would make a decision like this, but the options are pretty straightforward if they did.
  - tinco 5y ago
    Yes, why not? Must it absolutely be so that a 20 year old Macbook can run the latest kernel? One that isn't even released yet, it's just in the preliminary planning phase? It's not even like new software wouldn't run on it. Most software runs fine on 10 year old linux kernels. Also, by calling them 'users' you're anthropomorphising, who are these actual real human beings being "left behind"? edit: ok so it sounds a bit mean if you interpret it as if I'm not considering UnkleJoe to be a real human being. What I mean is, I don't think UnkleJoe is trying to get new devices to talk to his prehistoric PPC embedded system just for fun. An organisation is maintaining these systems, and that organisation is mooching off of Linux's excellent backwards compatibility. What's the economical cost of supporting that organisation, versus the economical costs of not implementing ksmbd in Rust?
lambda 5y ago
> Rust should not be used in the Linux kernel until it supports 100% of the architectures supported by Linux itself. Why is it that so many people feel like they need to make sweeping pronouncements on the exact compatibility guarantees that a project as large as the Linux kernel must maintain across its entire code base? Different maintainers of different subsystems of the Linux kernel make their own decisions on compatibility and support effort. There are a few basic principles shared across the project as a whole, such as user-space ABI compat guarantees, lack of kernel-space ABI guarantees, module licensing requirements, etc. Not every piece of hardware even exists in the form of a PCIe expansion card. Some drivers are for peripherals that are embedded into a specific line of systems-on-a-chip. If I'm writing a driver for some peripheral that only exists on an AWS Graviton chip, I don't see any reason why some HN commenter should dictate that that driver can't be written in Rust just because there isn't yet upstream LLVM support for DEC Alpha chips. I feel like most of these takes are due to someone getting upset a couple of years ago because some core library in Gnome like librsvg added a dependency on a Rust compiler back when rustc didn't yet support m68k systems, and this got someone working on packaging upset due to conflicting distro packaging policies. The world moves on, however. The Linux kernel drops support for old hardware all the time. It introduces features that might only work on certain hardware. Also, rustc has added support for more platforms, including moving some platforms like aarch64 to Tier 1 support, and adding support for m68k. While maintaining backwards compatibility or wide portability of drivers is a good thing, so is the much easier ability to write maintainable and secure code that Rust brings, so the desire to simply block one good thing that works on the vast majority of machines running Linux in favor of some small niche use cases doesn't really seem like the soundest decision.
structural 5y ago
I strongly disagree with your viewpoint. If you need to support plugging in new hardware to a very niche embedded architecture, you will still have many options. These range the gamut from writing a driver based on the reference driver for your environment, to requesting/funding the development of such C driver from the vendor, to funding support for your hardware architecture in Rust/LLVM. Yes, all of these cost time/money. Maintenance of software ports to various architectures is very much not zero-cost, and assuming it is will eventually bite you or your business hard. As another thought experiment: let's say the development of drivers in Rust is less expensive (either in $$$ spent on engineer time, in $$$ lost to bugs and security issues, or any other valuation you choose. If you/your community of people who desire new hardware to be supported by your embedded architecture can not cover this difference in cost (to make it worthwhile for drivers to be written for you), nor can afford to develop and maintain support for your architecture in Rust (so that you can benefit from the development work done by the vendor), nor can afford to upgrade to a newer hardware platform (which solves the problem completely), then your business is already screwed and you just don't realize it yet. That said, this is the responsible way to introduce Rust code to the kernel - if this had be done by limiting future releases of Linux to only those supported by Rust, I'd be out with my pitchfork too, because that's something that really needs to be planned very carefully. As long as stable kernel releases continue to exist that support the full set of architectures, everyone's existing code will keep working, receive security fixes, etc. This is fine.
synergy20 5y ago
Strongly agree here as a long time driver developer. I honestly don't see the point to rush rust into drivers in the kernel now, if anything, it makes the driver space even more complicated.
ysleepy 5y ago
That can be achieved by linux dropping support for architectures not supported by rust :D I'm joking of course, but the platform support list of rust is pretty good looking at [1]. I'm pretty sure people developing for arm5 aren't building the linux kernel on arm5. [1] https://doc.rust-lang.org/nightly/rustc/platform-support.html https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
- guenthert 5y ago
  Yes, x-compiling is certainly an option, particularly since developers typically have access to hardware easily capable of such (it's just a minor pain to set-up). Linux has always favored support for currently (and in the foreseeable future) relevant architectures over widest possible spread. I don't quite understand the desire to run recent software on museums piece hardware, but for those who must, there's NetBSD.
pabs3 5y ago
There are at least two efforts that support Rust with GCC (a rustc codegen backend that uses libgccjit for AOT compilation, and a GCC frontend that parses Rust). https://lwn.net/Articles/871283/ https://lwn.net/Articles/871283/ https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs https://github.com/antoyo/rustc_codegen_gcc https://github.com/antoyo/rustc_codegen_gcc
raxxorrax 5y ago
That is actually a good point, but on the other hand you have to start somewhere. I hope vendors would be more supportive of third party drivers because that obviously makes their hardware more attractive, but that has not been the case the last years. I also don't have an opinion on the rust foundation. Member setup doesn't convince me, hope it doesn't influence the language negatively.

johnisgood 5y ago

I completely agree. We should not get ahead of ourselves just yet. It seriously should support most if not all of the architectures that Linux itself supports. https://doc.rust-lang.org/nightly/rustc/platform-support.html https://doc.rust-lang.org/nightly/rustc/platform-support.htm... vs. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch?h=v5.16-rc4 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... or https://en.wikipedia.org/wiki/List_of_Linux-supported_computer_architectures https://en.wikipedia.org/wiki/List_of_Linux-supported_comput...

xxpor 5y ago
LLVM is the real bottleneck here. I've worked with a platform that would have been easy to build a custom rust for (even if it wasn't officially supported), but was held up by the lack of LLVM support.
- lambda 5y ago
  Yep. But there are two different active projects for compiling Rust with a GCC backend at the moment (one as a completely new frontend written as part of the GCC codebase, one as a libgccjit backend for the existing Rustc), there's also a Cranelift backend for rustc that you could add new architecture support to, and LLVM does add new targets, it can just take a bit longer to get support into LLVM and they don't keep architectures that are lightly or unmaintained around as long as GCC does. For instance, Tier 3 support for m68k-unknown-linux-gnu was recently stabilized in rustc as a result of m68k support landing in LLVM (https://github.com/rust-lang/rust/blob/master/RELEASES.md#compiler https://github.com/rust-lang/rust/blob/master/RELEASES.md#co...), which has been one of the previous sticking points for Rust packaging on Linux distros, some of which still support m68k architectures.

outworlder 5y ago

Chances are that Rust would also work just fine even if the arch is not officially 'supported', as long as LLVM exists on that platform. Also, this is not going to retroactively affect any drivers, only the ones (potentially) developed from now on. As time passes, Rust support is expected to increase.

kelnos 5y ago

> Rust should not be used in the Linux kernel until it supports 100% of the architectures supported by Linux itself. I don't think that's realistic. If we buy the idea that Rust will allow kernel developers to write more robust, safer, more secure drivers, I think that should override a desire to allow things like driver portability to arches that hardware manufacturers never expected or intended. I would judge that support to be a "nice to have", but it shouldn't block what I consider to be more important concerns (security and robustness). Regardless, the Rust support here is still considered experimental. I would be surprised if any company adopted it for a Linux driver for at least a year or more. That's plenty of time for people to get esoteric platforms supported in LLVM/Rust if they want to. And it also gives more time for the Rust GCC backend to become more mature and usable, and I believe that will give Rust support for every arch that GCC supports (more or less), which should cover your objection. (At any rate, LLVM+Rust does currently support PPC, so your specific argument here isn't relevant.)

sangnoir 5y ago
> I would judge that support to be a "nice to have", but it shouldn't block what I consider to be more important concerns (security and robustness). So what happens to users that depend on these archs & drivers - get left behind on the last non-Rust kernel?
- steveklabnik 5y ago
  The same as any other project that decides it may drop support: either stick on an old version, or work to add support for the platforms you care about. Rust's lack of platform support isn't because it is impossible for Rust to gain support for those platforms, but because users of those platforms haven't added support yet. Obviously that is easier said than done, and I doubt that Linux would make a decision like this, but the options are pretty straightforward if they did.
- tinco 5y ago
  Yes, why not? Must it absolutely be so that a 20 year old Macbook can run the latest kernel? One that isn't even released yet, it's just in the preliminary planning phase? It's not even like new software wouldn't run on it. Most software runs fine on 10 year old linux kernels. Also, by calling them 'users' you're anthropomorphising, who are these actual real human beings being "left behind"? edit: ok so it sounds a bit mean if you interpret it as if I'm not considering UnkleJoe to be a real human being. What I mean is, I don't think UnkleJoe is trying to get new devices to talk to his prehistoric PPC embedded system just for fun. An organisation is maintaining these systems, and that organisation is mooching off of Linux's excellent backwards compatibility. What's the economical cost of supporting that organisation, versus the economical costs of not implementing ksmbd in Rust?

lambda 5y ago

> Rust should not be used in the Linux kernel until it supports 100% of the architectures supported by Linux itself. Why is it that so many people feel like they need to make sweeping pronouncements on the exact compatibility guarantees that a project as large as the Linux kernel must maintain across its entire code base? Different maintainers of different subsystems of the Linux kernel make their own decisions on compatibility and support effort. There are a few basic principles shared across the project as a whole, such as user-space ABI compat guarantees, lack of kernel-space ABI guarantees, module licensing requirements, etc. Not every piece of hardware even exists in the form of a PCIe expansion card. Some drivers are for peripherals that are embedded into a specific line of systems-on-a-chip. If I'm writing a driver for some peripheral that only exists on an AWS Graviton chip, I don't see any reason why some HN commenter should dictate that that driver can't be written in Rust just because there isn't yet upstream LLVM support for DEC Alpha chips. I feel like most of these takes are due to someone getting upset a couple of years ago because some core library in Gnome like librsvg added a dependency on a Rust compiler back when rustc didn't yet support m68k systems, and this got someone working on packaging upset due to conflicting distro packaging policies. The world moves on, however. The Linux kernel drops support for old hardware all the time. It introduces features that might only work on certain hardware. Also, rustc has added support for more platforms, including moving some platforms like aarch64 to Tier 1 support, and adding support for m68k. While maintaining backwards compatibility or wide portability of drivers is a good thing, so is the much easier ability to write maintainable and secure code that Rust brings, so the desire to simply block one good thing that works on the vast majority of machines running Linux in favor of some small niche use cases doesn't really seem like the soundest decision.

structural 5y ago

I strongly disagree with your viewpoint. If you need to support plugging in new hardware to a very niche embedded architecture, you will still have many options. These range the gamut from writing a driver based on the reference driver for your environment, to requesting/funding the development of such C driver from the vendor, to funding support for your hardware architecture in Rust/LLVM. Yes, all of these cost time/money. Maintenance of software ports to various architectures is very much not zero-cost, and assuming it is will eventually bite you or your business hard. As another thought experiment: let's say the development of drivers in Rust is less expensive (either in $$$ spent on engineer time, in $$$ lost to bugs and security issues, or any other valuation you choose. If you/your community of people who desire new hardware to be supported by your embedded architecture can not cover this difference in cost (to make it worthwhile for drivers to be written for you), nor can afford to develop and maintain support for your architecture in Rust (so that you can benefit from the development work done by the vendor), nor can afford to upgrade to a newer hardware platform (which solves the problem completely), then your business is already screwed and you just don't realize it yet. That said, this is the responsible way to introduce Rust code to the kernel - if this had be done by limiting future releases of Linux to only those supported by Rust, I'd be out with my pitchfork too, because that's something that really needs to be planned very carefully. As long as stable kernel releases continue to exist that support the full set of architectures, everyone's existing code will keep working, receive security fixes, etc. This is fine.

synergy20 5y ago

Strongly agree here as a long time driver developer. I honestly don't see the point to rush rust into drivers in the kernel now, if anything, it makes the driver space even more complicated.

ysleepy 5y ago

That can be achieved by linux dropping support for architectures not supported by rust :D I'm joking of course, but the platform support list of rust is pretty good looking at [1]. I'm pretty sure people developing for arm5 aren't building the linux kernel on arm5. [1] https://doc.rust-lang.org/nightly/rustc/platform-support.html https://doc.rust-lang.org/nightly/rustc/platform-support.htm...

guenthert 5y ago
Yes, x-compiling is certainly an option, particularly since developers typically have access to hardware easily capable of such (it's just a minor pain to set-up). Linux has always favored support for currently (and in the foreseeable future) relevant architectures over widest possible spread. I don't quite understand the desire to run recent software on museums piece hardware, but for those who must, there's NetBSD.

pabs3 5y ago

There are at least two efforts that support Rust with GCC (a rustc codegen backend that uses libgccjit for AOT compilation, and a GCC frontend that parses Rust). https://lwn.net/Articles/871283/ https://lwn.net/Articles/871283/ https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs https://github.com/antoyo/rustc_codegen_gcc https://github.com/antoyo/rustc_codegen_gcc

raxxorrax 5y ago

That is actually a good point, but on the other hand you have to start somewhere. I hope vendors would be more supportive of third party drivers because that obviously makes their hardware more attractive, but that has not been the case the last years. I also don't have an opinion on the rust foundation. Member setup doesn't convince me, hope it doesn't influence the language negatively.