[Mesa-dev] rules for merging patches to libdrm

[Dave Airlie]

>> 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.

Dave.