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. Jerome
