[Mesa-dev] rules for merging patches to libdrm

[Rob Clark]

On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding
<thierry.reding at gmail.com> wrote:
> On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote:
>> 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.
>
> That doesn't sound like a bad idea at all. It obviously causes more work
> for whoever will be the gatekeeper(s).
>
> It seems to me that libdrm is currently more of a free-for-all type of
> project, and whoever merges some new feature required for a particular X
> or Mesa driver cuts a new release so that the version number can be used
> to track the dependency.
>
> I wonder if perhaps tying the libdrm releases more tightly to Linux
> kernel releases would help. Since there already is a requirement for new
> kernel APIs to be merged before the libdrm equivalent can be merged,
> then having both release cycles in lockstep makes some sense.

Not sure about strictly tying it to kernel releases would be ideal.
Not *everything* in libdrm is about new kernel APIs.  It tends to be
the place for things needed both by xorg ddx and mesa driver, which I
suppose is why it ends up a bit of a free-for-all.

Maybe limiting who does releases would be sufficient.  Unless there is
someone with enough free time and energy to volunteer to be libdrm
maintainer.

But tbh I don't think it has been too much of a problem in the past.
I'm not sure if I actually read somewhere the rule about not updating
kernel headers until the interface is locked in (ie. drm-next), but it
seemed like common sense to me.  Could be enough just to document this
a bit more explicitly.

BR,
-R



> Thierry
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>