[Mesa-dev] rules for merging patches to libdrm

[Thierry Reding]

On Mon, Nov 18, 2013 at 05:30:34PM +0100, Maarten Lankhorst wrote:
> op 09-11-13 22:26, Ian Romanick schreef:
> > 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.
> 
> Most of libdrm is hardware specific, so by necessity it is developed like that.

Most of the Linux kernel is hardware specific, yet it is developed
differently.

> I don't think robclark will touch libdrm/intel for example.

Certainly a subtree-oriented development model could work well for
libdrm. What I mean is that not a single person (or even a set of
people) would need to pick patches from a mailing list, but driver
maintainers could have separate trees which can be merged into the
upstream tree.

That could potentially lower the workload on the libdrm maintainer(s).

> I do not think explicit control is needed, just be more careful and don't cause
> unnecessary headaches by committing code to libdrm before it's in a upstream kernel.
> Preferably wait until it appears in torvalds/linux.git, but it seems airlied has a
> lower standard. :)
> 
> Sometimes software bugs might warrant a release too, so this middle area is needed.

Having a different development model doesn't exclude the possibility for
bugfix releases. Neither does explicit control of what patches are
merged.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/1db723ca/attachment.pgp>