From owner-freebsd-x11@freebsd.org Tue Jan 5 20:47:22 2016 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 A4DDDA63DDB for ; Tue, 5 Jan 2016 20:47:22 +0000 (UTC) (envelope-from n.pajkovsky@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E3491F4B; Tue, 5 Jan 2016 20:47:22 +0000 (UTC) (envelope-from n.pajkovsky@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id b14so47468055wmb.1; Tue, 05 Jan 2016 12:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=cYui1L+PT+mZxwq1i8YxA1qSSoywKSZjxGVK3NRKBJg=; b=Bw0Y6lqdCz9UWmH339ikc/hg05O1N54hJmZxTwI26vyk6NfU93lYOOwRcEa1qzw6rs HPD3piDuF/gVlyXJVAUIJqNieydiIVqQhKxOWmycEHe2IRet80wI27AYu7ZpYiu8Ycgy u82vCSYxTZGrJh9YPdCBDVKAAEcqpMDlpLld6LF0MaKvFukuuUy108aTb3UqGS0jMsDL Baxf21cbYN8i5wqm0JVfZ1g8EYpLfhGyyXZyzH5vAX2E4chp/l1xlmKeh2VN+gRsRowb 5C1YMMGK4LeOjX0BFdaXaiCNGWSu+Vpn1L168EnIfPswI0T+LevmCKHDE/j8hYZBCYA/ o8ew== X-Received: by 10.28.127.85 with SMTP id a82mr6489752wmd.48.1452026840776; Tue, 05 Jan 2016 12:47:20 -0800 (PST) Received: from localhost (ip-89-176-25-139.net.upcbroadband.cz. [89.176.25.139]) by smtp.gmail.com with ESMTPSA id q6sm92769988wjx.28.2016.01.05.12.47.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jan 2016 12:47:19 -0800 (PST) From: Nikola Pajkovsky To: =?utf-8?Q?Jean-S=C3=A9bastien_P=C3=A9dron?= Cc: "freebsd-x11\@freebsd.org" Subject: Re: Contributing to the kernel video drivers References: <5681731A.5090909@FreeBSD.org> Date: Tue, 05 Jan 2016 21:47:12 +0100 In-Reply-To: <5681731A.5090909@FreeBSD.org> (=?utf-8?Q?=22Jean-S=C3=A9bast?= =?utf-8?Q?ien_P=C3=A9dron=22's?= message of "Mon, 28 Dec 2015 18:36:26 +0100") Message-ID: <87egdv3ga7.fsf@gooddata.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Tue, 05 Jan 2016 20:47:22 -0000 Jean-S=C3=A9bastien P=C3=A9dron writes: > 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. > > 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 Pretty neat work. I have just boot up kernel and so far so good. >From my point of view, moving kernel by kernel does not make sense, because there are too much of them. However, moving long term kernel by long term kernel, makes more sense to me. I can imagine, that we can do that file-by-file basic until last lt-kernel. Where all code review happens? I haven't seen any here. Do you want to move forward with backporting? --=20 Nikola