Date: Fri, 08 Jan 2016 05:38:26 +0000 From: Leonard Rucker <leonard.rucker@gmail.com> To: Nikola Pajkovsky <n.pajkovsky@gmail.com>, =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= <dumbbell@freebsd.org> Cc: "freebsd-x11@freebsd.org" <freebsd-x11@freebsd.org> Subject: Re: Contributing to the kernel video drivers Message-ID: <CANeRTV_-px2EXF%2BY85rrOrnKL5bv1B6QumD79m%2Bi9M=wRjPoyA@mail.gmail.com> In-Reply-To: <87egdv3ga7.fsf@gooddata.com> References: <5681731A.5090909@FreeBSD.org> <87egdv3ga7.fsf@gooddata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <n.pajkovsky@gmail.com> wrote: > 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 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANeRTV_-px2EXF%2BY85rrOrnKL5bv1B6QumD79m%2Bi9M=wRjPoyA>