On Thu, 17 Oct 2019 at 06:00, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > > On Mon, Oct 14, 2019 at 2:16 PM Dave Airlie <airlied@xxxxxxxxx> wrote: > > > > I've kicked this around in my head over the past few weeks but wanted > > to get some feedback on whether it's a good idea or what impact it > > might have that I haven't considered. > > > > We are getting requests via both amdgpu/amdkfd and i915 for new user > > APIs for userspace drivers that throw code over the wall instead of > > being open source developed projects, but we are also seeing it for > > android drivers and kms properties, and we had that i915 crappy crtc > > background thing that was for Chrome but Chrome didn't want it. > > > > Now this presents a couple of issues: > > > > a) these projects don't seem to that good at following our development > > guidelines, avoid developing userspace features in parallel in the > > open and having good development implementations before submitting > > upstream. > > > > b) these projects don't have experienced userspace developers > > reviewing their kernel uapis. One big advantage of adding uapis with > > mesa developers is they have a lot of experience in the area as well. > > > > It's leading me to think I want to just stop all uapi submissions via > > driver trees, and instead mandate that all driver uapi changes are > > sent in separate git pull requests to dri-devel, I'd try (with some > > help) to catch all uapi modifications in normal trees, and refuse > > pulls that modified uapi. > > > > At least I'm considered writing the script and refusing and pulls that > > have a uapi change that doesn't contain a link to the userspace > > changes required for it in a public developed repo. > > > > Thoughts? > > This seems like more hassle for questionable benefits. I don't know > that mesa is really any better than any other driver teams with > respect to UAPI. This just seems like sort of a arbitrary political > decision. The people working on mesa have as much of an agenda as > those working on other projects. Moreover, especially with the > migration to gitlab and MRs, I feel that mesa development has gotten > more opaque. Say what you will about mailing lists, but at least you > could have a drive by view of what's going on. With MRs, you sort of > have to seek out what to review; if stuff is not tagged with something > you feel is relevant, you probably won't look at it, so the only > people likely to review it are the people involved in writing it in > the first place, which would be the same whether it's mesa or some > other project. I think all of the projects generally have the best > intentions at heart, but for better or worse they just have different > development models. In the case of the AMD throw it over the wall > stuff, it's not really an anti-open source or community engagement > issue, it's more of how to we support several OSes, tons of new > products, several custom projects, etc. while leveraging as much > shared code as possible. There are ways to make it work, but they are > usually a pretty heavy lift that not all teams can make. > > All of that said, I think providing a link to the userspace user of > the API is reasonable, but I don't think there have been any egregious > cases of badly designed UAPI that were not caught using the existing > processes. One advantage I forgot to state was that it gives me less reason to drop a complete pull request on the grounds that it contains some new uAPI that didn't follow the rules. This reduces the pressure on me and all the submaintainers. At the moment I'm inclined to let some simpler uapi changes past, because I don't want to drop complete feature pulls on the ground. I'm going to get stricter on this I suspect. Btw you can subscribe to all Mesa MR activity, I do it, I just ignore the ones I don't want to look at, just like I did for mailing lists. Even using MRs for Mesa still puts it streets ahead of any other userspace project in terms of insight into development, and hence trust of the developers involved. This is mostly about trust, currently I'd don't trust those teams to care enough or do the right thing. When we write down a bunch of rules about how this should work we get rules lawyering instead. I really don't want uapi development to be me with a magic eight ball, but it seems like that is where we will end up unless companies follow even the basic directions. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
