Date: Mon, 28 Dec 2015 22:54:59 +0100 From: =?UTF-8?Q?Jos=C3=A9_P=C3=A9rez?= <fbl@aoek.com> To: =?UTF-8?Q?Jean-S=C3=A9bastien_P=C3=A9dron?= <dumbbell@freebsd.org> Cc: freebsd-x11@freebsd.org, owner-freebsd-x11@freebsd.org Subject: Re: Contributing to the kernel video drivers Message-ID: <31762a600a9109918e1eb44b431b2012@mail.yourbox.net> 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 Jean-Sébastien, wow! I'm impressed. I'm in. For anything. Now, coming to the suggested commit-by-commit approach, I would like to draw your attention to the fact that recent hardware is only supported on latest versions of the drivers. If we want to have anything usable we shall give the word FreeBSD for recent hardware. Why don't we just pull in Linux 4.5? Am I the only one with the impression that FreeBSD is so way behind just because of this approach? Maybe we can speed up the import-from-linux task via some scripts that do automatically some basic stuff, such as sed 's/printk/DRM_ERROR/g' or adding i2c includes or changing the return sign of some functions. Any comment on this idea? Agree on the todo list. Agree on the github approach that mimics head policy. Regards, --- José Pérez El 2015-12-28 18:36, Jean-Sébastien Pédron escribió: > 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 > 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 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31762a600a9109918e1eb44b431b2012>