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