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. > Dave. > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
