Contributing to the kernel video drivers

[Jean-Sébastien Pédron]

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

-- 
Jean-Sébastien Pédron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20151228/46ba2a8a/attachment.sig>