From owner-freebsd-x11@freebsd.org Mon Dec 28 17:36:33 2015 Return-Path: Delivered-To: freebsd-x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C93D2A54489 for ; Mon, 28 Dec 2015 17:36:33 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9781C1A74 for ; Mon, 28 Dec 2015 17:36:33 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aDbih-0009CG-Ce for freebsd-x11@FreeBSD.org; Mon, 28 Dec 2015 18:36:31 +0100 From: =?UTF-8?Q?Jean-S=c3=a9bastien_P=c3=a9dron?= Subject: Contributing to the kernel video drivers X-Enigmail-Draft-Status: N1110 To: "freebsd-x11@freebsd.org" Message-ID: <5681731A.5090909@FreeBSD.org> Date: Mon, 28 Dec 2015 18:36:26 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iONk9hnw9dfjRWCLWXAscJ2rEnklC6F4f" X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 17:36:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iONk9hnw9dfjRWCLWXAscJ2rEnklC6F4f Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi! Several people already offerred their help to update video kernel drivers. I would like to discuss what is the best way to achieve team work here. Even though the work happens on GitHub, it has been difficult to contribute so far, because the gap with Linux was huge, it was difficult to coordinate work of several people, and I had no time to organize anything. My proposal is that we continue to work on GitHub, namely in: https://github.com/freebsd/freebsd-base-graphics In this repository, I would like to create a "drm-next". This branch could receive direct commits or pull requests. Once we feel it's in good shape, its content is committed to HEAD. It's close to how upstream works= =2E On a regular basis, we would merge HEAD in "drm-next" so the branch is in sync, especially if there are commits to DRM in Subversion directly. This "drm-next" branch should remain stable most of the time. If we need to break it for a longer period of time, we could use other branches, such as drm-next-i915, drm-next-dmabuf or drm-next-3.10 for isntance (these are just examples). They would be created from drm-next and they would have the same relationship with drm-next than drm-next has with HEA= D. Now, the complicated part is how to coordinate the work. I believe the milestones should be versions of Linux. For instance, the next one on the road is Linux 3.9. We have DRM core and two drivers to sync and I think we should try to keep the whole DRM in sync (and not have i915 at 3.15 and Radeon at 3.13 for instance). Until now, I updated our DRM on a file-by-file basis: I took a file from Linux 3.8 and ported it to FreeBSD from scratch, by keeping an eye on the current FreeBSD copy. Therefore, I jumped from whatever version we were at straight to 3.8, at the high cost of an unbuildable kernel before the very end. Another approach is to update on a commit-by-commit basis: we take all commits between 3.8 and 3.9 and apply them in order. The downside is that we could port code which is rewritten or removed 10 commits later. In both cases, we need a complete review of the code before it's committed to HEAD: a comparison to HEAD to make sure we don't drop needed code, a comparison to Linux to make sure the update is complete. An easy way to share the work is to split drivers: someone updates Radeon, someone else updates i915, a third contributor handles DRM. Still, this is not very parallel. If we go with the file-by-file update, it's very easy to parallelize further. With the commit-by-commit approach, it's complicated because it's obviously serialized. Again, if we go with the file-by-file method, we could jump to a later version of Linux instead of doing one at a time. It's even more dangerous because we have more chance of breaking/loosing something because of the gap between the last update and the next one. What do people think? Beside the DRM updates, there are other kernel tasks that can happen in parallel: o dmabuf / DRM PRIME o port new drivers (amdgpu is a priority) o monitor hotplug notifications o add a "link" between the /dev entry and a sysctl node (this is not specific to the video drivers) o move DRM to linuxkpi --=20 Jean-S=C3=A9bastien P=C3=A9dron --iONk9hnw9dfjRWCLWXAscJ2rEnklC6F4f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWgXMbXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMnk8P/2td6QVgA/G7MTU+SlaSGUph nsiwnN2ceXs2AIFiFUHkUE8gZhmuHE6m8jzIlGWlcoLpT9xA+4kg5EUTCoEsUTRs 25lxlN9M5ABvg9sYCokoBl0jbYpEwP8JsBVQ0947pjuhh8rN6Pc2kTpS4TcqA5Pj 7Im/ZDUpkiHdJu2cNgbrX199SdXvNZadw8jHKHrqyPWCkGX9vGvbK2AgD35kwkuB lnd3UaXjIqPGJaYBb+3y75uRr4ofKpYlRZ84DESi7rRH/WKjXAKDe1NhMZQ2no5H DYD5g0IKWAtlHLetu2N9O06Pb0Luj8lIdt/SK7oKhUd+VpeKQKwdQFsKzLU/aztv GOsz0ENziT30R2G18IL2MstZz+/hPCAQvnqcvyvh/8utjeitWW5TaxPfQsXoie5H 812LhRBIq/2dDSmZTDCDDQO+KkcZvFwP2+ShK4eZKxypGfzm8oCINMjJ30bOCVdk 4ZmeimjsvHPES7NqA/SM4zEBU8z04xm9ainwIkiW9bdFMGKkuud8nPIDd+EyJe4o LQwYXS7gSRW8MLfu8GI55wflNlmBhdodfZNZI01xZgtissagVCAjCawrBs9BLjOE sQU1qqTo5DN8qW1BmQH+3HO/UOQhUWaAxTneKu8hpGY+WU5TbFfPnyKwldoCZC2+ qhn7AXTk5nND2lIDBsEO =189G -----END PGP SIGNATURE----- --iONk9hnw9dfjRWCLWXAscJ2rEnklC6F4f--