[Mesa-dev] rules for merging patches to libdrm

[Rob Clark]

On Mon, Nov 18, 2013 at 10:23 AM, Thierry Reding
<thierry.reding at gmail.com> wrote:
> On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote:
>> 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.
>
> I didn't mean that every release would need to be tied to the Linux
> kernel. But whenever a new Linux kernel release was made, relevant
> changes from the public headers could be pulled into libdrm and a
> release be made. I could even imagine a matching of version numbers.
> libdrm releases could be numbered using the same major and minor as
> Linux kernels that they support. Micro version numbers could be used
> in intermediate releases.

maybe an update-kernel-headers.sh script to grab the headers from
drm-next and update libdrm wouldn't be a bad idea?


>> 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.
>
> It's not something I feel very strongly about. People seemed unhappy
> about the current state of affairs, so I thought I'd dump a few ideas.
> =)
>
> Thierry