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