On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote: >> On 11/09/2013 12:11 AM, Dave Airlie wrote: >> >>> How does this interact with the rule that kernel interfaces require an >> >>> open source userspace? Is "here are the mesa/libdrm patches that use >> >>> it" sufficient to get the kernel interface merged? >> >> >> >> That's my understanding: open source userspace needs to exist, but it >> >> doesn't need to be merged upstream yet. >> > >> > Having an opensource userspace and having it committed to a final repo >> > are different things, as Daniel said patches on the mesa-list were >> > sufficient, they're was no hurry to merge them considering a kernel >> > release with the code wasn't close, esp with a 3 month release window >> > if the kernel merge window is close to that anyways. >> > >> >>> libdrm is easy to change and its releases are cheap. What problem does >> >>> committing code that uses an in-progress kernel interface to libdrm >> >>> cause? I guess I'm not understanding something. >> >> >> > >> > Releases are cheap, but ABI breaks aren't so you can't just go release >> > a libdrm with an ABI for mesa then decide later it was a bad plan. >> > >> >> Introducing new kernel API usually involves assigning numbers for things >> >> - a new ioctl number, new #defines for bitfield members, and so on. >> >> >> >> Multiple patches can be in flight at the same time. For example, Abdiel >> >> and I both defined execbuf2 flags: >> >> >> >> #define I915_EXEC_RS (1 << 13) (Abdiel's code) >> >> #define I915_EXEC_OA (1 << 13) (my code) >> >> >> >> These obviously conflict. One of the two will land, and the second >> >> patch author will need to switch to (1 << 14) and resubmit. >> >> >> >> If we both decide to push to libdrm, we might get the order backwards, >> >> or maybe one series won't get pushed at all (in this case, I'm planning >> >> to drop my patch). Waiting until one lands in the kernel avoids that >> >> problem. Normally, I believe we copy the kernel headers to userspace >> >> and fix them up a bit. >> >> >> >> Dave may have other reasons; this is just the one I thought of. >> > >> > But mostly this, we've been stung by this exact thing happening >> > before, and we made the process to stop it from happening again. >> >> Then in all honestly, commits to libdrm should be controlled by either a >> single person or a small cabal... just like the kernel and the xserver. >> We're clearly in an uncomfortable middle area where we have a stringent >> set of restrictions but no way to actually enforce them. > > That doesn't sound like a bad idea at all. It obviously causes more work > for whoever will be the gatekeeper(s). > > It seems to me that libdrm is currently more of a free-for-all type of > project, and whoever merges some new feature required for a particular X > or Mesa driver cuts a new release so that the version number can be used > to track the dependency. > > I wonder if perhaps tying the libdrm releases more tightly to Linux > kernel releases would help. Since there already is a requirement for new > kernel APIs to be merged before the libdrm equivalent can be merged, > then having both release cycles in lockstep makes some sense. Not sure about strictly tying it to kernel releases would be ideal. Not *everything* in libdrm is about new kernel APIs. It tends to be the place for things needed both by xorg ddx and mesa driver, which I suppose is why it ends up a bit of a free-for-all. Maybe limiting who does releases would be sufficient. Unless there is someone with enough free time and energy to volunteer to be libdrm maintainer. But tbh I don't think it has been too much of a problem in the past. I'm not sure if I actually read somewhere the rule about not updating kernel headers until the interface is locked in (ie. drm-next), but it seemed like common sense to me. Could be enough just to document this a bit more explicitly. BR, -R > Thierry > > _______________________________________________ > mesa-dev mailing list > mesa-dev@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
