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 17:41:50 +0100 Message-ID: <20131118164149.GB30416@ulmo.nvidia.com> References: <527D6CBA.8020209@whitecape.org> <527EA880.4090902@freedesktop.org> <20131118132915.GD26046@ulmo.nvidia.com> <20131118152329.GJ26046@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1665647829==" 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: Rob Clark Cc: "mesa-dev@lists.freedesktop.org" , dri-devel List-Id: dri-devel@lists.freedesktop.org --===============1665647829== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V0207lvV8h4k8FAm" Content-Disposition: inline --V0207lvV8h4k8FAm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 18, 2013 at 11:21:36AM -0500, Rob Clark wrote: > On Mon, Nov 18, 2013 at 10:23 AM, Thierry Reding > wrote: > > 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 req= uire an > >> >> >>> open source userspace? Is "here are the mesa/libdrm patches tha= t use > >> >> >>> it" sufficient to get the kernel interface merged? > >> >> >> > >> >> >> That's my understanding: open source userspace needs to exist, b= ut 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 kern= el > >> >> > release with the code wasn't close, esp with a 3 month release wi= ndow > >> >> > if the kernel merge window is close to that anyways. > >> >> > > >> >> >>> libdrm is easy to change and its releases are cheap. What probl= em does > >> >> >>> committing code that uses an in-progress kernel interface to li= bdrm > >> >> >>> cause? I guess I'm not understanding something. > >> >> >> > >> >> > > >> >> > Releases are cheap, but ABI breaks aren't so you can't just go re= lease > >> >> > a libdrm with an ABI for mesa then decide later it was a bad plan. > >> >> > > >> >> >> Introducing new kernel API usually involves assigning numbers fo= r 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 sec= ond > >> >> >> patch author will need to switch to (1 << 14) and resubmit. > >> >> >> > >> >> >> If we both decide to push to libdrm, we might get the order back= wards, > >> >> >> or maybe one series won't get pushed at all (in this case, I'm p= lanning > >> >> >> to drop my patch). Waiting until one lands in the kernel avoids= that > >> >> >> problem. Normally, I believe we copy the kernel headers to user= space > >> >> >> 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 eit= her a > >> >> single person or a small cabal... just like the kernel and the xser= ver. > >> >> We're clearly in an uncomfortable middle area where we have a stri= ngent > >> >> 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 particul= ar 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. > >> > >> 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. >=20 > maybe an update-kernel-headers.sh script to grab the headers from > drm-next and update libdrm wouldn't be a bad idea? Perhaps. But I think it could even be a manual step. It's not something that one person should be doing alone, but rather something that driver maintainers should be doing, since they know best what will be needed in a new version of libdrm. Like I mentioned in another subthread, I think a subtree-oriented model could work well. Thierry --V0207lvV8h4k8FAm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSikNNAAoJEN0jrNd/PrOhBMsQAKd1WEH5q86APcKUXNbjCZBI A24obu8tSueoUmmFG+YXH6qWnPLqMV9AD1z5978UuwWsob788T4G/yuR5wygtdIz CMmmm99P2i7uMxKBW26ui/C943ZKwt7J//5s0dFG3NzL5fW+8h6EWaZS5dhSS1XI 8p2n+Ih+hVvHvEM4iGJotU/CFnYR9TdNWb8HE5dwyiBmMxBgR4fgZfg6lxbv6sWi gI6vSZlivq+EtWX/GO/3bW2HXgexBSroEJnXmVB77M+ivbD61EEYLQQU6US2KwQL 8sn8X8CqD9pb2ZBqjOd2VcuRtidcXgFhLiY4hEn4Jt/nuftwSDVAbP1/KHtjYQdg 1DWm3FzAuOQpdAh4TDMb29HEU6ylsZF+TNfBYQON3TydacyDGjjujjyPJkMCQ8wP 6MCBkvL3djcjslnq8YYmF9114nuTBXUzoBrqHwuUgH0PjPd1K0Ptoi3NdiT8XYW3 ubwnY2RrRzxWVNsxKVv7dZTl7WXfVGj85ok6j4lvs+Wyk6Ia8Mp/myzihajplbOj 4/jFQAeDKonmGfG3y53+4Jc7f6mbpPnPVTHQ5V6MKiQtSexWh3RjZ26uOVZeLdl/ 03fnl0OyX2IW1YtE7/Y5m6l/dQ+TS3MZRUkqm8RNgDxrx0Ms/bYi4FiYfS9x8Yp4 pHTz4fcECmte4gtibPvU =+YkN -----END PGP SIGNATURE----- --V0207lvV8h4k8FAm-- --===============1665647829== 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 --===============1665647829==--