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 16:23:30 +0100 Message-ID: <20131118152329.GJ26046@ulmo.nvidia.com> References: <527D6CBA.8020209@whitecape.org> <527EA880.4090902@freedesktop.org> <20131118132915.GD26046@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1119273886==" Return-path: In-Reply-To: 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: Rob Clark Cc: "mesa-dev@lists.freedesktop.org" , dri-devel List-Id: dri-devel@lists.freedesktop.org --===============1119273886== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j+MD90OnwjQyWNYt" Content-Disposition: inline --j+MD90OnwjQyWNYt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote: > On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding > wrote: > > 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 requir= e an > >> >>> open source userspace? Is "here are the mesa/libdrm patches that u= se > >> >>> 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 re= po > >> > 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 relea= se > >> > a libdrm with an ABI for mesa then decide later it was a bad plan. > >> > > >> >> Introducing new kernel API usually involves assigning numbers for t= hings > >> >> - a new ioctl number, new #defines for bitfield members, and so on. > >> >> > >> >> Multiple patches can be in flight at the same time. For example, A= bdiel > >> >> 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 backwar= ds, > >> >> or maybe one series won't get pushed at all (in this case, I'm plan= ning > >> >> to drop my patch). Waiting until one lands in the kernel avoids th= at > >> >> problem. Normally, I believe we copy the kernel headers to userspa= ce > >> >> 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 stringe= nt > >> 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. >=20 > Not sure about strictly tying it to kernel releases would be ideal. > Not *everything* in libdrm is about new kernel APIs. It tends to be > the place for things needed both by xorg ddx and mesa driver, which I > suppose is why it ends up a bit of a free-for-all. I didn't mean that every release would need to be tied to the Linux kernel. But whenever a new Linux kernel release was made, relevant changes from the public headers could be pulled into libdrm and a release be made. I could even imagine a matching of version numbers. libdrm releases could be numbered using the same major and minor as Linux kernels that they support. Micro version numbers could be used in intermediate releases. > Maybe limiting who does releases would be sufficient. Unless there is > someone with enough free time and energy to volunteer to be libdrm > maintainer. >=20 > But tbh I don't think it has been too much of a problem in the past. > I'm not sure if I actually read somewhere the rule about not updating > kernel headers until the interface is locked in (ie. drm-next), but it > seemed like common sense to me. Could be enough just to document this > a bit more explicitly. It's not something I feel very strongly about. People seemed unhappy about the current state of affairs, so I thought I'd dump a few ideas. =3D) Thierry --j+MD90OnwjQyWNYt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSijDxAAoJEN0jrNd/PrOht+IP/jEYZg8rdJ5SYxVmXaDnshHI dWUgoZaOQz8wKSDJDwyfwgh+U195/VITOhC0+ji31BSbUhUaY2ykfLUKIy3mPu8H wEsZAKPuiUuCJEovi2UkSLRM7ybg9HDb+ayLlYjaDi5Vpzw52WWA0DTzHmCY31og WDmNz9tPhQ+gWidHge5GoLSiMQCoEJfFnmXqy2wJdBaNAuWS5C8GYcS/l9B3Rea9 mmsvCwJk21mHz1tM3ep/Eod9+mMeE2PKNdk/QAWdov5zupq1W7Yn5DmxJ/z1MZbi Vw+z8xompQuH1VwPHXB8e0eCpqr/nWb4tbqMAJYax2hFWw5zSoEHJ/puMhQ0by4T YrMan0gewoj44Nvj9CzbHI/SqacnSIhiWxuD0Medego+sY6tc6dF5Oy4oimgdjx7 dw5jI4W63VqaUiHB0gI4Q/F6y/1JlckqrYfVsZD5bu/KH6AuKP3a6YQRZCi8pkbr DzCaHHN1QrawHBMLvWaangciTRjSee8GdelIrv01PVaAX8LU3R4pZgvNfeAJ+4ps cCEs5sB1VIwGXJtbEP8xvAttJ9Ymwv0qkHdWYP2LJOCP/KN4dikvjK1VgHx0Zyxz Hd+QslKtIYnXWW9zLjXx5rL+nkgXF7UndMeJPIXSzNANdIc7LeteYKHbsWP+M0AG +hAbotxL+dn+z/6p7vpD =Taqa -----END PGP SIGNATURE----- --j+MD90OnwjQyWNYt-- --===============1119273886== 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 --===============1119273886==--