Re: [Mesa-dev] rules for merging patches to libdrm

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4925 bytes --]

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel