[Mesa-dev] rules for merging patches to libdrm

Dave Airlie airlied at gmail.com
Sat Nov 9 00:11:53 PST 2013


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


More information about the dri-devel mailing list