Re: rules for merging patches to libdrm

[Ian Romanick <idr@freedesktop.org>]

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.

> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel