Re: Rust in our code base
will merge Rusticl tomorrow or so unless somebody complains. On Wed, Aug 24, 2022 at 5:34 PM Karol Herbst wrote: > > On Wed, Aug 24, 2022 at 5:18 PM Jason Ekstrand > wrote: > > > > +mesa-dev and my jlekstrand.net e-mail > > > > On Sun, 2022-08-21 at 20:44 +0200, Karol Herbst wrote: > > > On Sun, Aug 21, 2022 at 8:34 PM Rob Clark > > > wrote: > > > > > > > > On Sun, Aug 21, 2022 at 10:45 AM Karol Herbst > > > > wrote: > > > > > > > > > > On Sun, Aug 21, 2022 at 7:43 PM Karol Herbst > > > > > wrote: > > > > > > > > > > > > On Sun, Aug 21, 2022 at 5:46 PM Rob Clark > > > > > > wrote: > > > > > > > > > > > > > > On Sat, Aug 20, 2022 at 5:23 AM Karol Herbst > > > > > > > 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/15 > > > > > > > > 439) > > > > > > > > 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 > > > > > >
Re: Rust in our code base
On Wed, Aug 24, 2022 at 5:18 PM Jason Ekstrand wrote: > > +mesa-dev and my jlekstrand.net e-mail > > On Sun, 2022-08-21 at 20:44 +0200, Karol Herbst wrote: > > On Sun, Aug 21, 2022 at 8:34 PM Rob Clark > > wrote: > > > > > > On Sun, Aug 21, 2022 at 10:45 AM Karol Herbst > > > wrote: > > > > > > > > On Sun, Aug 21, 2022 at 7:43 PM Karol Herbst > > > > wrote: > > > > > > > > > > On Sun, Aug 21, 2022 at 5:46 PM Rob Clark > > > > > wrote: > > > > > > > > > > > > On Sat, Aug 20, 2022 at 5:23 AM Karol Herbst > > > > > > 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/15 > > > > > > > 439) > > > > > > > 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 > > > > >
