[Mesa-dev] rules for merging patches to libdrm

[Thierry Reding]

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.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/d3912c84/attachment.pgp>