3 ms·

I think you are operating under the assumption a fully compatible cross-compiler environment is already available in both languages. =3

steveklabnik 2y ago
Drivers are hardware specific, and so it's not a problem that Rust has support for a subset of the platforms that the kernel does. If you want to write a driver for a platform Rust doesn't support, just write it in C.
- Joel_Mckay 2y ago
  "If you want to write a driver for a platform Rust doesn't support, just write it in C." ¯\_(ツ)_/¯ Or a separate branch for Rust in the first place. We are falling into the circular reasoning logic loop. lol =3
- Muromec 2y ago
  Drivers are usually hardware specific but are not always platform specific. For example all the usb device drivers (but not host drivers) from x86 work just fine on arm and risc. And kernel isn’t just device drivers, but also stuff like network — higher level abstractions are decoupled from platform quite good. I don’t think there is practical intersection of platforms not supporting rust and running USB host, but by the time rust will creep into something line network subsystem code you will either not have network (which was working before) or you make yourself a rust compiler. This can mean dropping platform support. Maybe those are dead platforms, but somebody will make the argument that adding rust made things objectively worse.
  - steveklabnik 2y ago
    Sure. The point is, this is for new code where you know Rust supports the platform. It “creeping in” to something Rust can’t support won’t happen, because then the rust-less build will break. You are right that there are other policies that could work in a different way, but these policies were chosen specifically so that Rust doesn’t make the kernel sacrifice old platforms.
    - Joel_Mckay 2y ago
      'It “creeping in” to something Rust can’t support won’t happen' The exact same argument could be made for future architectural changes, as OpenBSD/FreeBSD/NetBSD build requirements will now beat Polyglot Linux in every metric of porting complexity moving forwards. We can't have it both ways... Best regards =3

steveklabnik 2y ago

Drivers are hardware specific, and so it's not a problem that Rust has support for a subset of the platforms that the kernel does. If you want to write a driver for a platform Rust doesn't support, just write it in C.

Joel_Mckay 2y ago
"If you want to write a driver for a platform Rust doesn't support, just write it in C." ¯\_(ツ)_/¯ Or a separate branch for Rust in the first place. We are falling into the circular reasoning logic loop. lol =3
Muromec 2y ago
Drivers are usually hardware specific but are not always platform specific. For example all the usb device drivers (but not host drivers) from x86 work just fine on arm and risc. And kernel isn’t just device drivers, but also stuff like network — higher level abstractions are decoupled from platform quite good. I don’t think there is practical intersection of platforms not supporting rust and running USB host, but by the time rust will creep into something line network subsystem code you will either not have network (which was working before) or you make yourself a rust compiler. This can mean dropping platform support. Maybe those are dead platforms, but somebody will make the argument that adding rust made things objectively worse.
- steveklabnik 2y ago
  Sure. The point is, this is for new code where you know Rust supports the platform. It “creeping in” to something Rust can’t support won’t happen, because then the rust-less build will break. You are right that there are other policies that could work in a different way, but these policies were chosen specifically so that Rust doesn’t make the kernel sacrifice old platforms.
  - Joel_Mckay 2y ago
    'It “creeping in” to something Rust can’t support won’t happen' The exact same argument could be made for future architectural changes, as OpenBSD/FreeBSD/NetBSD build requirements will now beat Polyglot Linux in every metric of porting complexity moving forwards. We can't have it both ways... Best regards =3