From owner-freebsd-x11@freebsd.org Fri Jan 8 05:38:37 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 30CF4A675FF for ; Fri, 8 Jan 2016 05:38:37 +0000 (UTC) (envelope-from leonard.rucker@gmail.com) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 DC0091290; Fri, 8 Jan 2016 05:38:36 +0000 (UTC) (envelope-from leonard.rucker@gmail.com) Received: by mail-vk0-x232.google.com with SMTP id i129so48237050vkb.0; Thu, 07 Jan 2016 21:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=t/HeJbrTWGon1QzrU0GSkfBv2lLnIAYscK2H59O6uZA=; b=TxiYJIuVYTa5UQdwq3DeR9sY/bmqsxuqKQP0vMlZeW82YxX/0sAXw8KS7+iZeR7he9 EQE6jj7xr/dPQ+ZWjdem1YoYGWFaALrlUdjawOE1NeyInM7zlaCpONYboZuQkZ0iGtqo oKiNH0kGQoKvfL2tGDZCeHs26Yh0K191nhPjUtMNy8XcTZfru2MaFhWohyAXPeB/zDZn yGQYMDDQJDIKxCicNmgsJXfU1lJ1pLRR6ZErLP5wGaoEw6ZFS1UBi4MskYx3FIRPxW67 6aH7KdIgp26KUvaZxuCP7wzibf6UradTTXsQQo+s4cnWuIiLjew8WHhtdIHkcxGAtv6o rrCg== X-Received: by 10.31.8.136 with SMTP id 130mr78932720vki.34.1452231515937; Thu, 07 Jan 2016 21:38:35 -0800 (PST) MIME-Version: 1.0 References: <5681731A.5090909@FreeBSD.org> <87egdv3ga7.fsf@gooddata.com> In-Reply-To: <87egdv3ga7.fsf@gooddata.com> From: Leonard Rucker Date: Fri, 08 Jan 2016 05:38:26 +0000 Message-ID: Subject: Re: Contributing to the kernel video drivers To: Nikola Pajkovsky , =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Cc: "freebsd-x11@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Fri, 08 Jan 2016 05:38:37 -0000 I like the file by file approach rather than walking commits. It may be hard for several people to work together while trying to update on a commit by commit basis. A file by file approach I think would be easier because a bunch of people can work on a couple of files each. Then theoretically we could have buildable kernels sooner once every one has done their part. I'd really like to help out too so I can wait to hear how you decide to move forward. Len On Tue, Jan 5, 2016 at 12:47 PM Nikola Pajkovsky wrote: > 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 difficul= t > > 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 goo= d > > 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 nee= d > > 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 > HEAD. > > > > 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 update= d > > our DRM on a file-by-file basis: I took a file from Linux 3.8 and porte= d > > 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? > > -- > Nikola > _______________________________________________ > freebsd-x11@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org"