op 09-11-13 22:26, Ian Romanick schreef: > 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. Most of libdrm is hardware specific, so by necessity it is developed like that. I don't think robclark will touch libdrm/intel for example. I do not think explicit control is needed, just be more careful and don't cause unnecessary headaches by committing code to libdrm before it's in a upstream kernel. Preferably wait until it appears in torvalds/linux.git, but it seems airlied has a lower standard. :) Sometimes software bugs might warrant a release too, so this middle area is needed. ~Maarten _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
