On Tue Mar 17, 2026 at 3:47 AM CET, Daniel Almeida wrote: > I agree with what Danilo said below, i.e.: IMHO, with the direction that DRM > is going, it is much more ergonomic to add a Rust component with a nice C > interface than doing it the other way around.
This is not exactly what I said. I was talking about the maintainance aspects and that a Rust Jobqueue implementation (for the reasons explained in my initial reply) is easily justifiable in this aspect, whereas another C implementation, that does *not* replace the existing DRM scheduler entirely, is much harder to justify from a maintainance perspective. I'm also not sure whether a C interface from the Rust side is easy to establish. We don't want to limit ourselves in terms of language capabilities for this and passing through all the additional infromation Rust carries in the type system might not be straight forward. It would be an experiment, and it was one of the ideas behind the Rust Jobqueue to see how it turns if we try. Always with the fallback of having C infrastructure as an alternative when it doesn't work out well. Having this said, I don't see an issue with the drm_dep thing going forward if there is a path to replacing DRM sched entirely. The Rust component should remain independent from this for the reasons mentioned in [1]. [1] https://lore.kernel.org/dri-devel/[email protected]/
