Date: Tue, 05 Jan 2016 21:47:12 +0100 From: Nikola Pajkovsky <n.pajkovsky@gmail.com> To: =?utf-8?Q?Jean-S=C3=A9bastien_P=C3=A9dron?= <dumbbell@FreeBSD.org> Cc: "freebsd-x11\@freebsd.org" <freebsd-x11@FreeBSD.org> Subject: Re: Contributing to the kernel video drivers Message-ID: <87egdv3ga7.fsf@gooddata.com> 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 %2B0100") References: <5681731A.5090909@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jean-S=C3=A9bastien P=C3=A9dron <dumbbell@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87egdv3ga7.fsf>