4 ms·

I don't see why Rust usage in the kernel should be blocked by GCC of all things. Of course kernel has been traditionally compiled by GCC, but there was never a

I don't see why Rust usage in the kernel should be blocked by GCC of all things. Of course kernel has been traditionally compiled by GCC, but there was never a ban on any additional or alternative tools. There is a number of dependencies on things like make, bison and so on.

busterarm 4y ago
You would care if you were on one of the dozen or so CPU architectures that would suddenly become unsupported.
- unrealhoang 4y ago
  Probably the Rust code will be drivers for devices that are not compatible with non-rust supported architectures anyway.
  - busterarm 4y ago
    Also true, but there's a precedent for Rust developers & shipping their changes without regard for what's being deprecated. [1] [1]: like when PyPI cryptography first switched to Rust and broke ansible/openwrt/etc.
    - ntoskrnl 4y ago
      The Linux kernel takes backwards compatibility much more seriously than your typical Python package.
      - busterarm 4y ago
        The Linux kernel community and Rust community still aren't on the same page on things yet, as you'll learn by reading lwn regularly. We're just not there yet.
        nindalf 4y ago
        Seems like Linus and Greg and a bunch of people who oversee technical decisions on the Linux kernel are on board though?
        humanwhosits 4y ago
        And they can back-out/revert if they decide to as well
    - merb 4y ago
      ansible... btw. ansible breaks basically tons of stuff every release, so no matter if the pypi crytography broke ansible. ansible is already broke. heck they renamed their package in the most stupid way ever...
  - Unklejoe 4y ago
    If the drivers are for PCI or USB devices, then they would have probably worked for those unsupported architectures "for free" if they were written in C.
    - nicoburns 4y ago
      By the time these kind of drivers are being written in Rust, the gcc support will be there anyway.
- josefx 4y ago
  I thought we are talking about Rust? Full official Tier 1 support for aarch64 and x86, why would you even want more? That is two, and let me say it again TWO fully supported CPU architectures, that is twice as many as your average computer needs. Nobody needs dozens, certainly not someone who wants to be a Rockstar Rust dev. . /s
  - btilly 4y ago
    There are lots of cases where you want more. For example Google's secure boot for Pixel uses the Titan M security chip, which is a RISC-V architecture. Still, looking at https://llvm.org/docs/CompilerWriterInfo.html https://llvm.org/docs/CompilerWriterInfo.html, it is hard to find an architecture that Clang won't support that is relevant to many people. And if someone does find one, well, Clang is open source and open to adding more architectures.
    - raxxorraxor 4y ago
      Secure boot for smartphones is one of the reasons why smartphones are so restrictive and oriented against the user instead of for him. They should drop the support.
  - kevin_thibedeau 4y ago
    The majority of microprocessors deployed in the world are using neither of these platforms. Some of their developers like having a featureful compiler for them.
esjeon 4y ago
* The kernel doesn't need all those new bells and whistles that Rust wants to offer in the future, at least not as fast as how they are being shipped. * The kernel requires stability. Building a kernel w/ rustc is like building a house on a flying bullet. * GCC is insanely good at porting to other architectures, something vendors have been relying on for a long long time. * Consistency in applying compile flags and optimizations. Idk, these are all I can think of right now.
- nindalf 4y ago
  > least not as fast as how they are being shipped. Could you give some examples of big features from the last 12 months? I can’t think of any big ones off hand. IIRC, just a large number of small improvements. > The kernel requires stability. I can’t recall a new Rust release ever breaking existing code. Is this what you’re talking about? > GCC Rust will have a GCC backend and/or frontend soon. > Consistency in applying compile flags and optimizations. Can’t say much about this but I’m fairly sure the kernel devs won’t let anything be merged until they’re satisfied. We can trust them on this.
  - estebank 4y ago
    > I can’t recall a new Rust release ever breaking existing code. Is this what you’re talking about? I have one case of code from late 2015 that stopped working in, IIRC, 2016, due to unsoundness being found in the borrow checker and it being fixed. error[E0713]: borrow may still be in use when destructor runs --> src/writer.rs:121:21 | 47 | impl<'a, F: Write + Read + Seek + 'a> Writer<'a, F> { | -- lifetime `'a` defined here ... 121 | Reader::new(self.file) | ------------^^^^^^^^^- returning this value requires that `*self.file` is borrowed for `'a` 122 | } | - here, drop of `self` needs exclusive access to `*self.file`, because the type `Writer<'_, F>` implements the `Drop` trait I ended up solving it by wrapping `self.file` in an "unnecessary" `Option` and using `Option::take` on `self.file` here. I guess I could have mucked around with `MaybeUninit` and risk UB instead, or removed the convenience `Drop` impl finalizer or made the impl non-generic. I haven't had a case of code no longer compiling since then.
  - 4y ago

busterarm 4y ago

You would care if you were on one of the dozen or so CPU architectures that would suddenly become unsupported.

unrealhoang 4y ago
Probably the Rust code will be drivers for devices that are not compatible with non-rust supported architectures anyway.
- busterarm 4y ago
  Also true, but there's a precedent for Rust developers & shipping their changes without regard for what's being deprecated. [1] [1]: like when PyPI cryptography first switched to Rust and broke ansible/openwrt/etc.
  - ntoskrnl 4y ago
    The Linux kernel takes backwards compatibility much more seriously than your typical Python package.
    - busterarm 4y ago
      The Linux kernel community and Rust community still aren't on the same page on things yet, as you'll learn by reading lwn regularly. We're just not there yet.
      - nindalf 4y ago
        Seems like Linus and Greg and a bunch of people who oversee technical decisions on the Linux kernel are on board though?
        humanwhosits 4y ago
        And they can back-out/revert if they decide to as well
  - merb 4y ago
    ansible... btw. ansible breaks basically tons of stuff every release, so no matter if the pypi crytography broke ansible. ansible is already broke. heck they renamed their package in the most stupid way ever...
- Unklejoe 4y ago
  If the drivers are for PCI or USB devices, then they would have probably worked for those unsupported architectures "for free" if they were written in C.
  - nicoburns 4y ago
    By the time these kind of drivers are being written in Rust, the gcc support will be there anyway.
josefx 4y ago
I thought we are talking about Rust? Full official Tier 1 support for aarch64 and x86, why would you even want more? That is two, and let me say it again TWO fully supported CPU architectures, that is twice as many as your average computer needs. Nobody needs dozens, certainly not someone who wants to be a Rockstar Rust dev. . /s
- btilly 4y ago
  There are lots of cases where you want more. For example Google's secure boot for Pixel uses the Titan M security chip, which is a RISC-V architecture. Still, looking at https://llvm.org/docs/CompilerWriterInfo.html https://llvm.org/docs/CompilerWriterInfo.html, it is hard to find an architecture that Clang won't support that is relevant to many people. And if someone does find one, well, Clang is open source and open to adding more architectures.
  - raxxorraxor 4y ago
    Secure boot for smartphones is one of the reasons why smartphones are so restrictive and oriented against the user instead of for him. They should drop the support.
- kevin_thibedeau 4y ago
  The majority of microprocessors deployed in the world are using neither of these platforms. Some of their developers like having a featureful compiler for them.

esjeon 4y ago

* The kernel doesn't need all those new bells and whistles that Rust wants to offer in the future, at least not as fast as how they are being shipped. * The kernel requires stability. Building a kernel w/ rustc is like building a house on a flying bullet. * GCC is insanely good at porting to other architectures, something vendors have been relying on for a long long time. * Consistency in applying compile flags and optimizations. Idk, these are all I can think of right now.

nindalf 4y ago
> least not as fast as how they are being shipped. Could you give some examples of big features from the last 12 months? I can’t think of any big ones off hand. IIRC, just a large number of small improvements. > The kernel requires stability. I can’t recall a new Rust release ever breaking existing code. Is this what you’re talking about? > GCC Rust will have a GCC backend and/or frontend soon. > Consistency in applying compile flags and optimizations. Can’t say much about this but I’m fairly sure the kernel devs won’t let anything be merged until they’re satisfied. We can trust them on this.
- estebank 4y ago
  > I can’t recall a new Rust release ever breaking existing code. Is this what you’re talking about? I have one case of code from late 2015 that stopped working in, IIRC, 2016, due to unsoundness being found in the borrow checker and it being fixed. error[E0713]: borrow may still be in use when destructor runs --> src/writer.rs:121:21 | 47 | impl<'a, F: Write + Read + Seek + 'a> Writer<'a, F> { | -- lifetime `'a` defined here ... 121 | Reader::new(self.file) | ------------^^^^^^^^^- returning this value requires that `*self.file` is borrowed for `'a` 122 | } | - here, drop of `self` needs exclusive access to `*self.file`, because the type `Writer<'_, F>` implements the `Drop` trait I ended up solving it by wrapping `self.file` in an "unnecessary" `Option` and using `Option::take` on `self.file` here. I guess I could have mucked around with `MaybeUninit` and risk UB instead, or removed the convenience `Drop` impl finalizer or made the impl non-generic. I haven't had a case of code no longer compiling since then.
- 4y ago