From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: rules for merging patches to libdrm Date: Mon, 18 Nov 2013 14:29:16 +0100 Message-ID: <20131118132915.GD26046@ulmo.nvidia.com> References: <527D6CBA.8020209@whitecape.org> <527EA880.4090902@freedesktop.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0022494965==" Return-path: In-Reply-To: <527EA880.4090902@freedesktop.org> 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: Ian Romanick Cc: "mesa-dev@lists.freedesktop.org" , dri-devel List-Id: dri-devel@lists.freedesktop.org --===============0022494965== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qGV0fN9tzfkG3CxV" Content-Disposition: inline --qGV0fN9tzfkG3CxV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. > >=20 > > 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. > >=20 > >>> 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. > >> > >=20 > > 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. > >=20 > >> Introducing new kernel API usually involves assigning numbers for thin= gs > >> - a new ioctl number, new #defines for bitfield members, and so on. > >> > >> Multiple patches can be in flight at the same time. For example, Abdi= el > >> 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. > >=20 > > But mostly this, we've been stung by this exact thing happening > > before, and we made the process to stop it from happening again. >=20 > 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. Thierry --qGV0fN9tzfkG3CxV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSihYrAAoJEN0jrNd/PrOhJLQP/AvOtUgYjgjJdm9nfcUy0CxA /RLzsH8r/Ebytf7+8VFWHbZP0tg9t5F6YfagnBfIfG/tITiZ/vAepzx3auEGvnHB 46AuFRrwUNaqmHoz84rCP0vmYADrWNmpT58VOwWadyusHUJF6xF5+acIftS0ONh9 n9PBAzi/qalO09AYeWg+lcq0uWh0n2g1ZYN3ktAaDx5HmoQo/efEL5ZQGZXnIDzU DgT1AuVk5Tkn/db690LHXvxj4470lFae0eLADrbvkQjgFsKlnJuTtxF+kJ5CPvmq JPxRSZLmJdSBLOu7Rck7JeihpdFSgryojG8nPmTprAbe5uaxtaZL2NCJ272fovU1 u4EKhfh2Ob0NR/ML+ADng1Y2ibBN2bjDE8L3sSINogEiricon/ryXfj8MxdDeUYk s1+b4Zodm/FJZPYNC7mb/nOROb5s9UM/UESeiDEabVTHLfCM7VMvLKCrAtU9hgOl YclNsgMthGVCib3GeVZnNheYknAIzH/ogAYIVihmvkk6kV9G+4lut3t2dvNbQMJ3 VI68r9qyOSdw2O5BJGRy/Tcx9oEoxp+j8TP5AAwRse7QfyWA516CKVc9/1aGmrcB 2az8BtDmyY+UCKf7+zbH5n5njOCdOtCMOF7/hjQgds5g+fHPbcInks9EP5CzlLHn d3S7sVhSA5f8Tfw2XWVS =othj -----END PGP SIGNATURE----- --qGV0fN9tzfkG3CxV-- --===============0022494965== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev --===============0022494965==--