On Sun, Aug 21, 2022 at 7:43 PM Karol Herbst <kherbst@xxxxxxxxxx> wrote: > > On Sun, Aug 21, 2022 at 5:46 PM Rob Clark <robdclark@xxxxxxxxx> wrote: > > > > On Sat, Aug 20, 2022 at 5:23 AM Karol Herbst <kherbst@xxxxxxxxxx> 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. > > > > yeah, I agree here. I wouldn't say it's all the responsibility of > developers changing APIs to also know how to change the code. So e.g. > if an MR fails to compile and it's because of rusticl, I will help out > and do the changes myself if necessary. But long term we have to > accept that API changes also come with the implication of also having > to touch Rust code. > > Short term it might be a learning opportunity for some/most, but long > term it has to be accepted as a part of development to deal with Rust. > > > 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. > > > > Yep, I fully agree here. This is also the main reason I am bringing > this up. Nobody should be left alone with having to deal with changing > the code. On the other hand a "not having to touch Rust code when > changing APIs" guarantee is something which is simply impossible to > have in any sane architecture. So we should figure out under which > circumstances it will be okay for everybody. > > At least I don't see a way how I can structure Rusticl so that > somebody working on gallium won't have to also deal with rusticl. One > possibility would be to have a libgallium.so file I can link to, but > then it's all about "stable gallium API" vs "not having to touch rust > code" and I hope everybody prefers the second :) > uhm... I meant "stable gallium API" vs "dealing with Rust code on API changes" > > 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. > > > > At least for Rusticl it's all within meson/ninja. We use bindgen to > generate the bindings automatically so you simply run into compilation > issues. And for the kernel side I think that Linus wanted Rust to be > non optional. If something uses it, you also make sure the Rust side > compiles. And the build system is dynamic enough that you can also > wire up bindgen and make it part of the normal development model. > > In regards to code tooling, for rust you usually rely on > rust-analyzer. I've already figured out with dcbaker on how to > integrate our meson setup with that. Atm I am able to get the full > experience with VScode. Not sure if we also need to figure out how > that can work with e.g. vim and how to deal with C <=> Rust > boundaries. > > > 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 > > > > >
