From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: rules for merging patches to libdrm Date: Tue, 19 Nov 2013 09:18:49 +0100 Message-ID: <20131119081848.GA31504@ulmo.nvidia.com> References: <527D6CBA.8020209@whitecape.org> <527EA880.4090902@freedesktop.org> <20131118132915.GD26046@ulmo.nvidia.com> <20131118152329.GJ26046@ulmo.nvidia.com> <20131118164149.GB30416@ulmo.nvidia.com> <20131118183854.GA14617@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0467281592==" Return-path: In-Reply-To: <20131118183854.GA14617@gmail.com> 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: Jerome Glisse Cc: "mesa-dev@lists.freedesktop.org" , dri-devel List-Id: dri-devel@lists.freedesktop.org --===============0467281592== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 18, 2013 at 01:38:55PM -0500, Jerome Glisse wrote: > On Mon, Nov 18, 2013 at 05:41:50PM +0100, Thierry Reding wrote: > > 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= 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 exis= t, but it > > > >> >> >> doesn't need to be merged upstream yet. > > > >> >> > > > > >> >> > Having an opensource userspace and having it committed to a f= inal 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 releas= e window > > > >> >> > if the kernel merge window is close to that anyways. > > > >> >> > > > > >> >> >>> libdrm is easy to change and its releases are cheap. What p= roblem does > > > >> >> >>> committing code that uses an in-progress kernel interface t= o libdrm > > > >> >> >>> cause? I guess I'm not understanding something. > > > >> >> >> > > > >> >> > > > > >> >> > Releases are cheap, but ABI breaks aren't so you can't just g= o release > > > >> >> > a libdrm with an ABI for mesa then decide later it was a bad = plan. > > > >> >> > > > > >> >> >> Introducing new kernel API usually involves assigning number= s 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 exa= mple, 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 av= oids 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 happeni= ng > > > >> >> > before, and we made the process to stop it from happening aga= in. > > > >> >> > > > >> >> 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 m= ore work > > > >> > for whoever will be the gatekeeper(s). > > > >> > > > > >> > It seems to me that libdrm is currently more of a free-for-all t= ype of > > > >> > project, and whoever merges some new feature required for a part= icular 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 Li= nux > > > >> > kernel releases would help. Since there already is a requirement= for new > > > >> > kernel APIs to be merged before the libdrm equivalent can be mer= ged, > > > >> > 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, whic= h 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? > >=20 > > 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. > >=20 > > Like I mentioned in another subthread, I think a subtree-oriented model > > could work well. > >=20 > > Thierry >=20 > Please stop asking for more process bureaucracy. libdrm development model > works fine. Everyone is free to commit and release when needed. The recent > hickup is just that a hickup and does not warrant any changes. It didn't sound like everything was fine. From the above, the same has happened before. Also more process doesn't necessarily mean more bureaucracy. It helps with coordinating work and avoid stepping on each other's toes. That's not something I consider bad or unnecessary overhead. That said, I don't have a particular problem with how libdrm is developed. I wasn't asking for anything. It seemed like people weren't happy with the way things are working right now and a discussion about possible ways to remedy the situation ensued. I don't consider any of those proposals to make things more difficult in any significant way, just perhaps more structured and organized. Now if everybody is indeed fine with the way things work then there's no point in this discussion and I'll just shut up. Thierry --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSix7oAAoJEN0jrNd/PrOh9vwQAKjd3UMNZqdVdCWYtJGc489q tBgh/H1ad55KoyMf++tRSUZX7sI5uVXwOA6c780D87v0sqOf6sWUvPhd+mPYLLfr 1rUmpov2jcVU2SuNcf89vxXvENR4RQF/oiT1u+LP5n0aQv1VTfDpy4R1UzyQZLvA 3kMd70IoiuWJPqeSA9Y8RTOad4WTuLSAppoxhrt3ny+O8+lfEnDKE58N3dT+q4qP Ohw6I/Y6RrokSTH0FDSZJqIFNZ2SAjU7tN3LuJb8cR5RbQfIEiaLXhxKyOlnG0qc om1Qx1oewQQH5WKSeEa39v0GW2UVuHNfQINBMzI6NABSkkpOI+R4Dze9zmis0NMp D6nr8cxILDWEdd5zfB5RQHIsQQNrOKSs63mmoRmZPKCCGBmnBzZwtsQTP+zRfHBI UH+tz7yr+Go7QV4/ZvN+fA6J/AXXE85G7tTwiARLfJMsFkiMVtKjwQH7tcD7FWUk bhVj4T5mlQthehkow6dpItBSccIFU1WboeFC5m47hczOlCjKsRp7JWhMqQHIozIH hoL624icBi0hfne6IbkPjGHJ+MmpJ7O25byUdx01buqy3KHn+Vp66k2Noc4uPos7 uEEw37o0DStFnzWz+WaKr1qrcCz4IuK8pSZW/kl4wf8RRzBnTcJzznUo8K4Ys+UW CJ9MZ6B3I1TdH5cKc8fh =Vz2Y -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- --===============0467281592== 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 --===============0467281592==--