From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Romanick Subject: Re: rules for merging patches to libdrm Date: Sat, 09 Nov 2013 13:26:24 -0800 Message-ID: <527EA880.4090902@freedesktop.org> References: <527D6CBA.8020209@whitecape.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mesa-dev-bounces@lists.freedesktop.org Errors-To: mesa-dev-bounces@lists.freedesktop.org To: Dave Airlie Cc: "mesa-dev@lists.freedesktop.org" , dri-devel List-Id: dri-devel@lists.freedesktop.org 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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel