From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [Mesa-dev] rules for merging patches to libdrm Date: Mon, 18 Nov 2013 17:38:30 +0100 Message-ID: <20131118163829.GA30416@ulmo.nvidia.com> References: <527D6CBA.8020209@whitecape.org> <527EA880.4090902@freedesktop.org> <528A40AA.3060300@canonical.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1138136305==" Return-path: In-Reply-To: <528A40AA.3060300@canonical.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: Maarten Lankhorst Cc: "mesa-dev@lists.freedesktop.org" , dri-devel List-Id: dri-devel@lists.freedesktop.org --===============1138136305== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 18, 2013 at 05:30:34PM +0100, Maarten Lankhorst wrote: > 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 do= es > >>>> 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 thi= ngs > >>> - a new ioctl number, new #defines for bitfield members, and so on. > >>> > >>> Multiple patches can be in flight at the same time. For example, Abd= iel > >>> 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 planni= ng > >>> 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. >=20 > Most of libdrm is hardware specific, so by necessity it is developed like= that. Most of the Linux kernel is hardware specific, yet it is developed differently. > I don't think robclark will touch libdrm/intel for example. Certainly a subtree-oriented development model could work well for libdrm. What I mean is that not a single person (or even a set of people) would need to pick patches from a mailing list, but driver maintainers could have separate trees which can be merged into the upstream tree. That could potentially lower the workload on the libdrm maintainer(s). > 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 upstr= eam kernel. > Preferably wait until it appears in torvalds/linux.git, but it seems airl= ied has a > lower standard. :) >=20 > Sometimes software bugs might warrant a release too, so this middle area = is needed. Having a different development model doesn't exclude the possibility for bugfix releases. Neither does explicit control of what patches are merged. Thierry --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSikKFAAoJEN0jrNd/PrOhqBcP/1COjMaLkrD0D9+4oh2h1QXO iYjfencVXRAmZ7RVfH1bPwdw+pVknAJZhBWHMnt4kK/r3oXCgehwa9Zfe0hqjDZY KkelRFcMKTwjSIs36du06XCl0smIUgQ33i502tyrrKT5/jTtdMq2xe/8xKLyMNo8 bcO1tEmmba0mxTgnL+k7a1jYriHZNhT3zPdn1ya1gSNHBmDSqj1fZV6QB3ZPmP7K M3S43tgZBQdAdKIyRYXq75pTb0CK8Mx1Zwba88hdXaZap+Yl01rfzp5AOjxnY4K5 JMeNbwNwYYlFjhSO++jK2BWqQ1Cyt+CPhjZDCvfVxnUfWn+pWs8U04/8VtcLxKqM eHjdCxypsbtWUwkqjuS4JYiFBOcGPiQu3Ijvc3K91Ght49dsMofVGzi/Jfuoo0TD ZrHW7xDiuJ3I28cla0Z7XksaWnN8iqdAI2YX2QcB9TTOs7jcPW8j4w+XKvCzeQue /fUjk98aCxWLIAkklvn4PvZGrlxAwfY2J5F13ML0ljIsiEjCBTnLwj6S3Msa6/4V pt6s9HQnQHYPj7gYEgRkmJrP+6W2ciWEqt+qRi6Tl4JYUu2WObNXWUGi61onHCfI fMuttSeDDakOW8eoFl5eq3hKHMU9hhjpfqcHaTsuRg1BfOsi+3VJINxeGukwPZLN 9U6EAK/jssP+USrb5ORb =+W2T -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- --===============1138136305== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1138136305==--