On Sat, Aug 20, 2022 at 5:23 AM Karol Herbst <kher...@redhat.com> wrote: > > Hey everybody, > > so I think it's time to have this discussion for real. > > I am working on Rusticl > (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15439) > which I would like to merge quite soon. > > Others might also plan on starting kernel drivers written in Rust (and > if people feel comfortable to discuss this as well, they might reply > here) > > The overall implication of that is: if we are doing this, people (that > is we) have to accept that touching Rust code will be part of our > development process. There is no other sane way of doing it. > > I am not willing to wrap things in Rusticl so changing gallium APIs > won't involve touching Rust code, and we also can't expect people to > design their kernel drivers in weird ways "just because somebody > doesn't want to deal with Rust" > > If we are going to do this, we have to do it for real, which means, > Rust code will call C APIs directly and a change in those APIs will > also require changes in Rust code making use of those APIs. > > I am so explicit on this very point, because we had some discussion on > IRC where this was seen as a no-go at least from some people, which > makes me think we have to find a mutual agreement on how it should be > going forward. > > And I want to be very explicit here about the future of Rusticl as > well: if the agreement is that people don't want to have to deal with > Rust changing e.g. gallium, Rusticl is a dead project. I am not > willing to come up with some trashy external-internal API just to > maintain Rusticl outside of the mesa git repo. > And doing it on a kernel level is even more of a no-go. > > So what are we all thinking about Rust in our core repos?
I think there has to be willingness on the part of rust folks to help others who aren't so familiar with rust with these sorts of API changes. You can't completely impose the burden on others who have never touched rust before. That said, I expect a lot of API changes over time are simple enough that other devs could figure out the related rust side changes. As long as folks who want to start introducing rust in mesa and drm realize they are also signing up to play the role of rust tutor and technical assistance, I don't see a problem. But if they aren't around and willing to help, I could see this going badly. I do also wonder a bit about code tooling (indexers, etc).. I'm not sure what the state of things when it comes to cross c<->rust integration. Ie. it is usually straightforward enough to track down all the spots in C code which would be affected by some change. It might be easier to overlook things on the rust side. On the mesa side, pre-merge CI jobs help to catch these issues. Less sure about how to handle that on the kernel side. BR, -R > CCing a bunch of people who think are the most impacted by it either > from a reviewer/maintainer or developer perspective. If you think some > others should be explicitly aware of this, please point them to this > discussion here. > > Karol >
