On Tue Mar 17, 2026 at 3:25 PM CET, Daniel Almeida wrote: > > >> On 17 Mar 2026, at 09:31, Danilo Krummrich <[email protected]> wrote: >> >> 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. > > Ok, I misunderstood your point a bit. > >> >> 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. > > From previous experience in doing Rust to C FFI in NVK, I don’t see, at > first, why this can’t work. But I agree with you, there may very well be > unanticipated things here and this part is indeed an experiment. No argument > from me here. > >> >> 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 issues I pointed out remain. Even if the plan is to have drm_dep + > JobQueue > (and no drm_sched). I feel that my point of considering doing it in Rust > remains.
I mean, as mentioned below, we should have a Rust Jobqueue as independent component. Or are you saying you'd consdider having only a Rust component with a C API eventually? If so, that'd be way too early to consider for various reasons. >> The Rust component should remain independent from this for the reasons >> mentioned >> in [1]. >> >> [1] https://lore.kernel.org/dri-devel/[email protected]/ > > Ok > > — Daniel
