[Mesa-dev] rules for merging patches to libdrm

[Maarten Lankhorst]

op 09-11-13 22:26, Ian Romanick schreef:
> 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.

Most of libdrm is hardware specific, so by necessity it is developed like that.
I don't think robclark will touch libdrm/intel for example.

I do not think explicit control is needed, just be more careful and don't cause
unnecessary headaches by committing code to libdrm before it's in a upstream kernel.
Preferably wait until it appears in torvalds/linux.git, but it seems airlied has a
lower standard. :)

Sometimes software bugs might warrant a release too, so this middle area is needed.

~Maarten