[Mesa-dev] rules for merging patches to libdrm

[Thierry Reding]

On Mon, Nov 18, 2013 at 01:38:55PM -0500, Jerome Glisse wrote:
> On Mon, Nov 18, 2013 at 05:41:50PM +0100, Thierry Reding wrote:
> > On Mon, Nov 18, 2013 at 11:21:36AM -0500, Rob Clark wrote:
> > > 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?
> > 
> > Perhaps. But I think it could even be a manual step. It's not something
> > that one person should be doing alone, but rather something that driver
> > maintainers should be doing, since they know best what will be needed
> > in a new version of libdrm.
> > 
> > Like I mentioned in another subthread, I think a subtree-oriented model
> > could work well.
> > 
> > Thierry
> 
> Please stop asking for more process bureaucracy. libdrm development model
> works fine. Everyone is free to commit and release when needed. The recent
> hickup is just that a hickup and does not warrant any changes.

It didn't sound like everything was fine. From the above, the same has
happened before. Also more process doesn't necessarily mean more
bureaucracy. It helps with coordinating work and avoid stepping on each
other's toes. That's not something I consider bad or unnecessary
overhead.

That said, I don't have a particular problem with how libdrm is
developed. I wasn't asking for anything. It seemed like people weren't
happy with the way things are working right now and a discussion about
possible ways to remedy the situation ensued. I don't consider any of
those proposals to make things more difficult in any significant way,
just perhaps more structured and organized.

Now if everybody is indeed fine with the way things work then there's no
point in this discussion and I'll just shut up.

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/20131119/9ff12076/attachment.pgp>