13 ms·

A very helpful summary from r/rust on the same topic [1] >A few notes for people who haven't been tracking the Rust-in-kernel situation. Drivers especially hav

A very helpful summary from r/rust on the same topic [1] >A few notes for people who haven't been tracking the Rust-in-kernel situation. Drivers especially have been targeted for a few reasons. First, drivers are isolated, with abstractions that don't require interaction with the rest of the system. Second, Linux is available on more systems than the Rust compiler has been ported to. Because drivers are inherently system-dependent, it is not an issue to introduce a dependency on rustc on compatible systems. Third, bugs tend to arise more in drivers than other parts of the codebase, so Rust can do the most good starting there. [1] https://www.reddit.com/r/rust/comments/rb50yn/comment/hnmshsw https://www.reddit.com/r/rust/comments/rb50yn/comment/hnmshs...

Waterluvian 5y ago
Seems like a brilliant fit for introducing Rust to Linux kernel.
vlovich123 5y ago
> The GCC backend for the Rust compiler (through `libgccjit`, although used for ahead-of-time compilation) was merged into upstream Rust: https://github.com/rust-lang/rustc_codegen_gcc https://github.com/rust-lang/rustc_codegen_gcc If the backend keeps progressing, we hope to soon be able to start experimenting with compiling the Rust side of the kernel with GCC! This means that using it for the core parts may be feasible sooner rather than later, no? Developing those abstractions may not be a priority of course, but it might be allowable at least from a platform support perspective.
- kibwen 5y ago
  Even once Rust has first-class support for GCC as a backend, I suspect that supporting the long tail of more obscure platforms will be an ongoing process. And for exceptionally weird platforms (e.g. where a byte isn't 8 bits) Rust may never bother to contort itself enough to support those, although perhaps Linux also doesn't support such platforms?
  - JoshTriplett 5y ago
    > Even once Rust has first-class support for GCC as a backend, I suspect that supporting the long tail of more obscure platforms will be an ongoing process. Linux's own support for the long tail of more obscure platforms is also an ongoing process. People aren't asking for Rust to do better than the Linux kernel in that regard, they're just asking for it to not immediately disqualify a range of platforms. One could reasonably argue about the value of supporting those platforms, but the Linux kernel, reasonably, doesn't want to make that decision on the sole basis of the availability of Rust support. > And for exceptionally weird platforms (e.g. where a byte isn't 8 bits) Rust may never bother to contort itself enough to support those, although perhaps Linux also doesn't support such platforms? Linux doesn't support such platforms, and I don't think Rust ever will either.
    - account42 5y ago
      > Linux doesn't support such platforms, and I don't think Rust ever will either. Almost all software not written especially for such devices doesn't support non-8-platforms. Heck, POSIX mandates that char is 8 bits.
  - xxpor 5y ago
    FWIW Linux does support s390 (n.b., not to be confused with s390x), which is a 31 bit arch. Rust does not support it (and I'd guess LLVM doesn't either). So Linux does support some "weird" arches still. This is partially what caused the shitstorm when the python Cryptography library took a hard dependency on rust to compile: https://github.com/pyca/cryptography/issues/5771 https://github.com/pyca/cryptography/issues/5771
    - cesarb 5y ago
      AFAIK, s390 also has 8-bit bytes. The "31 bits" is the pointer size; IIRC, it's actually 32 bits, but with one bit reserved for compatibility with its even older predecessors.
    - woodruffw 5y ago
      Linux has not had mainline support for s390 since Linux 4.1 (6 years ago). Only s390x is left. You can still run 31-bit s390 usermode binaries on an s390x kernel, but that's a different beast.
- quotemstr 5y ago
  > This means that using it for the core parts may be feasible sooner rather than later, no? More like much later. There are several performance-critical patterns used in the Linux kernel that are difficult to express in unsafe Rust and impossible to express in safe Rust. See https://paulmck.livejournal.com/62436.html https://paulmck.livejournal.com/62436.html and especially https://paulmck.livejournal.com/64209.html https://paulmck.livejournal.com/64209.html I think promoting the use of Rust for driver code is an excellent compromise. As an aside, I'd like to see Linux go further and move many of these drivers to user space. Now that we have io_uring, old performance-based arguments for keeping certain drivers in ring 0 hold less weight.
- noobermin 5y ago
  Just a guess, use of the gcc backend for rust will face hard opposition by the same people pushing for rust in the kernel specifically if it is chosen (as it should be) by the kernel as the default choice.
throwaway894345 5y ago
I'd be very curious if anyone knows what the Rust team's ambitions are for supporting the full set of Linux-supported platforms? Is this something they aspire toward? If so, how are they approaching it? Working with LLVM folks? Other backends (e.g., gcc)?
- jamincan 5y ago
  The rustc compiler uses LLVM, so whatever new architectures LLVM supports, rustc also gets. There are two projects going on right now - rustc_codegen_gcc which adds GCC as a rustc backend, and gcc-rs which adds a rust frontend to GCC. Both have seen considerable progress and support over the past year and are probably the most promising avenue to expanding the architectures that rust can compile to.
- steveklabnik 5y ago
  Not on the relevant team, but I can tell you what I've observed from the outside: There's no specific goal to support every platform Linux supports. We have four tiers of support: 1-3, and then not supported in-tree. The project itself only moves things forward on a given platform if there are people championing that platform's support. If folks want to get Rust in more than just drivers and into the kernel proper, and platform support is an issue, then it's up to them to drive the platform support. For example, aarch64-unknown-linux-gnu only recently gained Tier 1 support, thanks to Arm themselves driving the effort. For the details on what is supported today, and the process to expand that list: https://doc.rust-lang.org/stable/rustc/platform-support.html https://doc.rust-lang.org/stable/rustc/platform-support.html Here's an example of a contributor adding a new platform at tier 3: https://github.com/rust-lang/rust/pull/79608 https://github.com/rust-lang/rust/pull/79608
b20000 5y ago
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 understand how to build custom drivers and tune the kernel for specific applications, so i don’t need or want another language involved in there. in the end, you still need to understand what you are doing, and rust is not going to change that. the days that linux was only used as a secure server OS are long gone. it is used everywhere for all kinds of applications and by lots of small manufacturers who are using the pi or other platforms. also, you cannot just develop a driver in isolation, you have to take the typical use cases in mind while you make choices how to handle things.
- 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.
megous 5y ago
> with abstractions that don't require interaction with the rest of the system I have no idea what this is supposed to mean. Drivers obviously interact with each other and with the rest of the system via all kinds of in-kernel interfaces. Drivers are also not inherently system dependent. Even the sample rust driver is for android binder, which is not a real HW device, but some kind of IPC mechanism. So that one is quite system independent.
- tatref 5y ago
  The target architectures of the rust compiler are very limited compared to GCC. So if you port some core functionality of the kernel to rust, that would make rust a hard dependency for the whole kernel.
  - megous 5y ago
    You missed the point.
  - fault1 5y ago
    OTOH, it may cause companies to invest in creating a well maintained Rust frontend for gcc. People have already done much of the grunt work for this, so it seems like it's just a matter of manpower, and something that acceptance into the edges of the kernel might cause more investment in.
- Tuna-Fish 5y ago
  > I have no idea what this is supposed to mean. Drivers obviously interact with each other and with the rest of the system via all kinds of in-kernel interfaces. But the total footprint of the interfaces that typical drivers use is fairly small. When a rusty shim is provided that provides access to those interfaces, you can write pure rust drivers.
  - megous 5y ago
    Typical device drivers with limited interface footprint also barely do anything interesting. For example look at typical audio codec drivers. They barely have any procedural code (and when they do it's just some form of register value mapping anyway), locking/concurency and almost all resource management is handled at the higher level and the driver is not exposed to it. Another kind of a driver that features a very limited dependency on Linux interfaces is a SoC clock/reset driver. And clock drivers are even more boring in this aspect. Code vs data ratio is probably < 0.1 in many of those. I guess some drivers that do more complicated stuff, and deal with concurrency issues or more complicated resource management may benefit, but they'll likely need to touch much larger API surface, too. And I dunno, even the sample driver in the patchset has things like this: let mut data = kernel::new_device_data!( gpio::RegistrationWithIrqChip::new(), PL061Resources { // SAFETY: This device doesn't support DMA. base: unsafe { IoMem::try_new(res)? }, parent_irq: irq, }, // SAFETY: We call `spinlock_init` below. unsafe { SpinLock::new(PL061Data::default()) }, "PL061::Registrations" )?; // SAFETY: General part of the data is pinned when `data` is. let gen = unsafe { data.as_mut().map_unchecked_mut(|d| &mut **d) }; kernel::spinlock_init!(gen, "PL061::General"); let data = Ref::<DeviceData>::from(data); It's barely readable. I don't know what type `data` is, what `gen` is or how it's different from `data`. Variable names don't really help. `data.as_mut().map_unchecked_mut(|d| &mut *d)` also looks like some kind of WTF to the uninitiated, that is somehow retrieving some 'general part of data' whatever that is. When I look at the kernel's spinlock type https://elixir.bootlin.com/linux/latest/source/include/linux/spinlock_types.h#L17 https://elixir.bootlin.com/linux/latest/source/include/linux... that doesn't really help me determine why whatever this `gen` [variable?] is needs to be passed to `spinlock_init`. And what's with the two `let data`. Are they the same type or is the type now different and the first data variable now hidden? Because it looks like second `let data` gets somehow transformed from the first `data` into something else. So now we have two identically named `data` variables with different types in the same function? Wasn't this supposed to be some simpler language to draw more people to the kernel development? At least with C each variable has a type that's quickly identifiable. I guess after 15 minutes I see what this is trying to do. It passes some newly created spinlock object to `new_device_data` function and then calls `spinlock_init` on some part of the data returned from `new_device_data` that needs to be extracted from it via some really obtuse transformation, just to initialize the spinlock later instead of directly in `SpinLock::new` for some obscure reason, using two unsafe {} blocks in the process. But oh my god, if this kind of obfuscation is going to be the new standard for the kernel,... At least C is the devil I know. :)
Unklejoe 5y ago
> 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.
wolverine876 5y ago
Who wrote that? Why do you have confidence in it?

Waterluvian 5y ago

Seems like a brilliant fit for introducing Rust to Linux kernel.

vlovich123 5y ago

> The GCC backend for the Rust compiler (through `libgccjit`, although used for ahead-of-time compilation) was merged into upstream Rust: https://github.com/rust-lang/rustc_codegen_gcc https://github.com/rust-lang/rustc_codegen_gcc If the backend keeps progressing, we hope to soon be able to start experimenting with compiling the Rust side of the kernel with GCC! This means that using it for the core parts may be feasible sooner rather than later, no? Developing those abstractions may not be a priority of course, but it might be allowable at least from a platform support perspective.

kibwen 5y ago
Even once Rust has first-class support for GCC as a backend, I suspect that supporting the long tail of more obscure platforms will be an ongoing process. And for exceptionally weird platforms (e.g. where a byte isn't 8 bits) Rust may never bother to contort itself enough to support those, although perhaps Linux also doesn't support such platforms?
- JoshTriplett 5y ago
  > Even once Rust has first-class support for GCC as a backend, I suspect that supporting the long tail of more obscure platforms will be an ongoing process. Linux's own support for the long tail of more obscure platforms is also an ongoing process. People aren't asking for Rust to do better than the Linux kernel in that regard, they're just asking for it to not immediately disqualify a range of platforms. One could reasonably argue about the value of supporting those platforms, but the Linux kernel, reasonably, doesn't want to make that decision on the sole basis of the availability of Rust support. > And for exceptionally weird platforms (e.g. where a byte isn't 8 bits) Rust may never bother to contort itself enough to support those, although perhaps Linux also doesn't support such platforms? Linux doesn't support such platforms, and I don't think Rust ever will either.
  - account42 5y ago
    > Linux doesn't support such platforms, and I don't think Rust ever will either. Almost all software not written especially for such devices doesn't support non-8-platforms. Heck, POSIX mandates that char is 8 bits.
- xxpor 5y ago
  FWIW Linux does support s390 (n.b., not to be confused with s390x), which is a 31 bit arch. Rust does not support it (and I'd guess LLVM doesn't either). So Linux does support some "weird" arches still. This is partially what caused the shitstorm when the python Cryptography library took a hard dependency on rust to compile: https://github.com/pyca/cryptography/issues/5771 https://github.com/pyca/cryptography/issues/5771
  - cesarb 5y ago
    AFAIK, s390 also has 8-bit bytes. The "31 bits" is the pointer size; IIRC, it's actually 32 bits, but with one bit reserved for compatibility with its even older predecessors.
  - woodruffw 5y ago
    Linux has not had mainline support for s390 since Linux 4.1 (6 years ago). Only s390x is left. You can still run 31-bit s390 usermode binaries on an s390x kernel, but that's a different beast.
quotemstr 5y ago
> This means that using it for the core parts may be feasible sooner rather than later, no? More like much later. There are several performance-critical patterns used in the Linux kernel that are difficult to express in unsafe Rust and impossible to express in safe Rust. See https://paulmck.livejournal.com/62436.html https://paulmck.livejournal.com/62436.html and especially https://paulmck.livejournal.com/64209.html https://paulmck.livejournal.com/64209.html I think promoting the use of Rust for driver code is an excellent compromise. As an aside, I'd like to see Linux go further and move many of these drivers to user space. Now that we have io_uring, old performance-based arguments for keeping certain drivers in ring 0 hold less weight.
noobermin 5y ago
Just a guess, use of the gcc backend for rust will face hard opposition by the same people pushing for rust in the kernel specifically if it is chosen (as it should be) by the kernel as the default choice.

throwaway894345 5y ago

I'd be very curious if anyone knows what the Rust team's ambitions are for supporting the full set of Linux-supported platforms? Is this something they aspire toward? If so, how are they approaching it? Working with LLVM folks? Other backends (e.g., gcc)?

jamincan 5y ago
The rustc compiler uses LLVM, so whatever new architectures LLVM supports, rustc also gets. There are two projects going on right now - rustc_codegen_gcc which adds GCC as a rustc backend, and gcc-rs which adds a rust frontend to GCC. Both have seen considerable progress and support over the past year and are probably the most promising avenue to expanding the architectures that rust can compile to.
steveklabnik 5y ago
Not on the relevant team, but I can tell you what I've observed from the outside: There's no specific goal to support every platform Linux supports. We have four tiers of support: 1-3, and then not supported in-tree. The project itself only moves things forward on a given platform if there are people championing that platform's support. If folks want to get Rust in more than just drivers and into the kernel proper, and platform support is an issue, then it's up to them to drive the platform support. For example, aarch64-unknown-linux-gnu only recently gained Tier 1 support, thanks to Arm themselves driving the effort. For the details on what is supported today, and the process to expand that list: https://doc.rust-lang.org/stable/rustc/platform-support.html https://doc.rust-lang.org/stable/rustc/platform-support.html Here's an example of a contributor adding a new platform at tier 3: https://github.com/rust-lang/rust/pull/79608 https://github.com/rust-lang/rust/pull/79608

b20000 5y ago

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 understand how to build custom drivers and tune the kernel for specific applications, so i don’t need or want another language involved in there. in the end, you still need to understand what you are doing, and rust is not going to change that. the days that linux was only used as a secure server OS are long gone. it is used everywhere for all kinds of applications and by lots of small manufacturers who are using the pi or other platforms. also, you cannot just develop a driver in isolation, you have to take the typical use cases in mind while you make choices how to handle things.

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.

megous 5y ago

> with abstractions that don't require interaction with the rest of the system I have no idea what this is supposed to mean. Drivers obviously interact with each other and with the rest of the system via all kinds of in-kernel interfaces. Drivers are also not inherently system dependent. Even the sample rust driver is for android binder, which is not a real HW device, but some kind of IPC mechanism. So that one is quite system independent.

tatref 5y ago
The target architectures of the rust compiler are very limited compared to GCC. So if you port some core functionality of the kernel to rust, that would make rust a hard dependency for the whole kernel.
- megous 5y ago
  You missed the point.
- fault1 5y ago
  OTOH, it may cause companies to invest in creating a well maintained Rust frontend for gcc. People have already done much of the grunt work for this, so it seems like it's just a matter of manpower, and something that acceptance into the edges of the kernel might cause more investment in.
Tuna-Fish 5y ago
> I have no idea what this is supposed to mean. Drivers obviously interact with each other and with the rest of the system via all kinds of in-kernel interfaces. But the total footprint of the interfaces that typical drivers use is fairly small. When a rusty shim is provided that provides access to those interfaces, you can write pure rust drivers.
- megous 5y ago
  Typical device drivers with limited interface footprint also barely do anything interesting. For example look at typical audio codec drivers. They barely have any procedural code (and when they do it's just some form of register value mapping anyway), locking/concurency and almost all resource management is handled at the higher level and the driver is not exposed to it. Another kind of a driver that features a very limited dependency on Linux interfaces is a SoC clock/reset driver. And clock drivers are even more boring in this aspect. Code vs data ratio is probably < 0.1 in many of those. I guess some drivers that do more complicated stuff, and deal with concurrency issues or more complicated resource management may benefit, but they'll likely need to touch much larger API surface, too. And I dunno, even the sample driver in the patchset has things like this: let mut data = kernel::new_device_data!( gpio::RegistrationWithIrqChip::new(), PL061Resources { // SAFETY: This device doesn't support DMA. base: unsafe { IoMem::try_new(res)? }, parent_irq: irq, }, // SAFETY: We call `spinlock_init` below. unsafe { SpinLock::new(PL061Data::default()) }, "PL061::Registrations" )?; // SAFETY: General part of the data is pinned when `data` is. let gen = unsafe { data.as_mut().map_unchecked_mut(|d| &mut **d) }; kernel::spinlock_init!(gen, "PL061::General"); let data = Ref::<DeviceData>::from(data); It's barely readable. I don't know what type `data` is, what `gen` is or how it's different from `data`. Variable names don't really help. `data.as_mut().map_unchecked_mut(|d| &mut *d)` also looks like some kind of WTF to the uninitiated, that is somehow retrieving some 'general part of data' whatever that is. When I look at the kernel's spinlock type https://elixir.bootlin.com/linux/latest/source/include/linux/spinlock_types.h#L17 https://elixir.bootlin.com/linux/latest/source/include/linux... that doesn't really help me determine why whatever this `gen` [variable?] is needs to be passed to `spinlock_init`. And what's with the two `let data`. Are they the same type or is the type now different and the first data variable now hidden? Because it looks like second `let data` gets somehow transformed from the first `data` into something else. So now we have two identically named `data` variables with different types in the same function? Wasn't this supposed to be some simpler language to draw more people to the kernel development? At least with C each variable has a type that's quickly identifiable. I guess after 15 minutes I see what this is trying to do. It passes some newly created spinlock object to `new_device_data` function and then calls `spinlock_init` on some part of the data returned from `new_device_data` that needs to be extracted from it via some really obtuse transformation, just to initialize the spinlock later instead of directly in `SpinLock::new` for some obscure reason, using two unsafe {} blocks in the process. But oh my god, if this kind of obfuscation is going to be the new standard for the kernel,... At least C is the devil I know. :)

Unklejoe 5y ago

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

wolverine876 5y ago

Who wrote that? Why do you have confidence in it?