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.red...@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.red...@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
pgpCufboUzZ0I.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
