Date: Tue, 29 Dec 2015 22:21:05 +0100 From: Bertram Scharpf <lists@bertram-scharpf.de> To: freebsd-x11@freebsd.org Subject: Re: Contributing to the kernel video drivers Message-ID: <20151229212105.GA89977@becker.bs.l> In-Reply-To: <5681731A.5090909@FreeBSD.org> References: <5681731A.5090909@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Monday, 28. Dec 2015, 18:36:26 +0100, Jean-S=C3=A9bastien P=C3=A9dron wr= ote: > My proposal is that we continue to work on GitHub, namely in: > https://github.com/freebsd/freebsd-base-graphics >=20 > [...] >=20 > Now, the complicated part is how to coordinate the work. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. As I am not actually experienced in kernel hacking, it is difficult for me to give a qualified answer here. Probably writing file-by-file needs a higher level of discipline what I regard as an advantage. Because I am a kernel noob, I depend on detailed instructions for the beginning. These perhaps can be expressed easier with the file-by-file method. Bertram --=20 Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151229212105.GA89977>