4 ms·

I wonder how Microsoft implements rust in their kernel. As for this issue, it's just a nature of any project, people will come and go regardless, so why not le

I wonder how Microsoft implements rust in their kernel. As for this issue, it's just a nature of any project, people will come and go regardless, so why not let those C developers leave and keep the rust folks instead? At some point you have to steer the ship and there will always be a group of people unhappy about the course

000ooo000 2y ago
MBA moment
bigfatkitten 2y ago
Alternatively, there's nothing preventing the Rust folks building their own kernel from the ground up.
- dralley 2y ago
  There are multiple kernels written in Rust already. Writing another one wouldn't be interesting. The point of R4L is that people want to write drivers for Linux in Rust. The corporate sponsors that are involved also are interested in writing drivers for Linux in Rust. Sure, Google could rebase Android on top of RedoxOS or Fuschia and Red Hat could spend a decade writing Linux Subsystem for RedoxOS, but neither want to do those things. They want to write drivers, for Linux, in Rust. Telling them to write a new kernel is a bit like telling them they should go write a new package manager. It's a completely different thing from what they actually care about.
  - patrick451 2y ago
    [flagged]
    - dralley 2y ago
      Both Linus and Greg KH were actively supportive of the project and remain so. Several of the R4L developers were long-term linux devs long before the project started (e.g. David Arlie). There are lots of current maintainers who aren't directly involved with R4L that still have a positive and optimistic outlook about it long-term. Just because there are a handful of maintainers are vocally in opposition does not mean that is the representative opinion. This is such an absurd, content-free argument, which is not surprising given how you closed it.
    - tcfhgj 2y ago
      That's a good reputation to have, for most people
    - vlakreeh 2y ago
      Ah yes, woke, the word used to describe something disliked. That's a misrepresentation of what's actually going on in the R4L project. Volunteers are enabling support for it within the kernel to allow for rust drivers in a way that explicitly does not require existing maintainers to change how they maintain their parts of the kernel. Maintaining rust support and the APIs consumed by Rust is the job of R4L and doesn't require any work from the existing maintainers who are allowed to make changes to their C that breaks Rust where the Rust will then be adjusted accordingly.
- baq 2y ago
  The kernel is not a problem. Drivers are. If it wasn’t for drivers we’d all be rolling our own custom kernels.
malkia 2y ago
Microsoft allows C++ in the kernel too, but what I'm wondering how SEH would be handled there. For example reading from user provided memory that maybe invalid, you need "__try/__catch" there. https://github.com/microsoft/windows-drivers-rs/blob/main/examples/sample-umdf-driver/src/lib.rs https://github.com/microsoft/windows-drivers-rs/blob/main/ex...
- malkia 2y ago
  hum - yeah - https://github.com/microsoft/windows-drivers-rs/issues/6 https://github.com/microsoft/windows-drivers-rs/issues/6
EasyMark 2y ago
or they can be adults and work it out. Sometimes you just ahve to put the kids in different sandboxes and keep them apart, that's why we have APIs and calling conventions.
jeroenhd 2y ago
From what I can tell, Microsoft seems to have the advantage that a lot of in-kernel interfaces are documented and relatively stable. Linux guarantees that the userland APIs don't change, but when a kernel component changes you're out of luck. Windows seems much more focused on internal consistency and stability. Probably in part because a lot of proprietary software uses a lot of internal APIs not meant for public consumption and there's nothing Microsoft can do to stop that, really. In a way, these Rust bindings are somewhat stabilizing the Linux API as well, by putting more expectations and implications from documentation into compiler-validated code. However, this does imply certain changes are sure to break any Rust driver code one might encounter, and if may take Rust devs a while to redesign the interfaces to maintain compatibility. It's hardly a full replacement for a stable API. At the moment, there aren't enough Rust developers to take over kernel maintenance. Those Rust developers would also need to accept giant code trees from companies updating their drivers, so you need experts in both. With the increasing amount of criticism languages like C are receiving online because we now have plain better tooling, I think the amount of new C developers will diminish over the coming years, but it still may take decades for the balance to shift.

000ooo000 2y ago

MBA moment

bigfatkitten 2y ago

Alternatively, there's nothing preventing the Rust folks building their own kernel from the ground up.

dralley 2y ago
There are multiple kernels written in Rust already. Writing another one wouldn't be interesting. The point of R4L is that people want to write drivers for Linux in Rust. The corporate sponsors that are involved also are interested in writing drivers for Linux in Rust. Sure, Google could rebase Android on top of RedoxOS or Fuschia and Red Hat could spend a decade writing Linux Subsystem for RedoxOS, but neither want to do those things. They want to write drivers, for Linux, in Rust. Telling them to write a new kernel is a bit like telling them they should go write a new package manager. It's a completely different thing from what they actually care about.
- patrick451 2y ago
  [flagged]
  - dralley 2y ago
    Both Linus and Greg KH were actively supportive of the project and remain so. Several of the R4L developers were long-term linux devs long before the project started (e.g. David Arlie). There are lots of current maintainers who aren't directly involved with R4L that still have a positive and optimistic outlook about it long-term. Just because there are a handful of maintainers are vocally in opposition does not mean that is the representative opinion. This is such an absurd, content-free argument, which is not surprising given how you closed it.
  - tcfhgj 2y ago
    That's a good reputation to have, for most people
  - vlakreeh 2y ago
    Ah yes, woke, the word used to describe something disliked. That's a misrepresentation of what's actually going on in the R4L project. Volunteers are enabling support for it within the kernel to allow for rust drivers in a way that explicitly does not require existing maintainers to change how they maintain their parts of the kernel. Maintaining rust support and the APIs consumed by Rust is the job of R4L and doesn't require any work from the existing maintainers who are allowed to make changes to their C that breaks Rust where the Rust will then be adjusted accordingly.
baq 2y ago
The kernel is not a problem. Drivers are. If it wasn’t for drivers we’d all be rolling our own custom kernels.

malkia 2y ago

Microsoft allows C++ in the kernel too, but what I'm wondering how SEH would be handled there. For example reading from user provided memory that maybe invalid, you need "__try/__catch" there. https://github.com/microsoft/windows-drivers-rs/blob/main/examples/sample-umdf-driver/src/lib.rs https://github.com/microsoft/windows-drivers-rs/blob/main/ex...

malkia 2y ago
hum - yeah - https://github.com/microsoft/windows-drivers-rs/issues/6 https://github.com/microsoft/windows-drivers-rs/issues/6

EasyMark 2y ago

or they can be adults and work it out. Sometimes you just ahve to put the kids in different sandboxes and keep them apart, that's why we have APIs and calling conventions.

jeroenhd 2y ago

From what I can tell, Microsoft seems to have the advantage that a lot of in-kernel interfaces are documented and relatively stable. Linux guarantees that the userland APIs don't change, but when a kernel component changes you're out of luck. Windows seems much more focused on internal consistency and stability. Probably in part because a lot of proprietary software uses a lot of internal APIs not meant for public consumption and there's nothing Microsoft can do to stop that, really. In a way, these Rust bindings are somewhat stabilizing the Linux API as well, by putting more expectations and implications from documentation into compiler-validated code. However, this does imply certain changes are sure to break any Rust driver code one might encounter, and if may take Rust devs a while to redesign the interfaces to maintain compatibility. It's hardly a full replacement for a stable API. At the moment, there aren't enough Rust developers to take over kernel maintenance. Those Rust developers would also need to accept giant code trees from companies updating their drivers, so you need experts in both. With the increasing amount of criticism languages like C are receiving online because we now have plain better tooling, I think the amount of new C developers will diminish over the coming years, but it still may take decades for the balance to shift.