[aw1621107]

Once again, congrats to the R4L team! It's a big milestone and I'm looking forwards to future developments!.

There was a lot of interesting discussion on the previous post [0], but one thing I didn't see was much discussion about this bit:

> The DRM (graphics) subsystem has been an early adopter of the Rust language. It was still perhaps surprising, though, when Airlie (the DRM maintainer) said that the subsystem is only "about a year away" from disallowing new drivers written in C and requiring the use of Rust.

I was a bit surprised when I first read this. Is this meant to be read in a way that is more just a description of the state of Rust bindings (e.g., the DRM subsystem is about a year away from being able to require the use of Rust, but isn't actually planning on doing so), or it is describing actual plans (e.g., the DRM subsystem is about a year away from actually requiring the use of Rust)? I was originally more inclined to go for the former interpretation, but this other bit:

> With regard to adding core-kernel dependencies on Rust code, Airlie said that it shouldn't happen for another year or two.

Makes me think that perhaps the devs are actually considering the latter. Is anyone more in-the-know able to comment on this?

[0]: https://news.ycombinator.com/item?id=46213585

[pitaj]

I'm not more "in the know" but it makes sense that new drivers could require it. New drivers, after all, are pretty much always written for newer platforms that Rust has support for. The main issue with enabling Rust (let alone requiring it) is that Linux still supports platforms which Rust does not.

[tonfa]

Is DRM considered core kernel dependencies?

[aw1621107]

I don't know. My line of thinking is that if the Linux devs are comfortable with using Rust in core Linux then they might also be comfortable requiring Rust for new drivers as well. No idea if that makes sense, though.