[Mesa-dev] rules for merging patches to libdrm

[Kenneth Graunke]

On 11/08/2013 02:32 PM, Matt Turner wrote:
> On Fri, Nov 8, 2013 at 11:29 AM, Dave Airlie <airlied at gmail.com> wrote:
>> Since we seemed to have some confusion over this I'll state it clearly here.
>>
>> You should not merge kernel interface and ioctls to libdrm until they
>> have appeared in a git commit upstream with a stable id, this
>> generally means drm-next, but can also mean drm-intel-next.
> 
> 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.

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

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.

--Ken