Contributing to the kernel video drivers

[Denis D]

On 28 December 2015 at 23:55, Jean-Sébastien Pédron <dumbbell at freebsd.org>
wrote:

> On 28/12/2015 22:54, José Pérez wrote:
> > 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?
>
> That is something we should decide during this discussion. Big jumps are
> dangerous because the difference between the current code and the new
> code is large. Therefore, it's difficult to better understand the actual
> changes and difficult to review. Furthermore, it will take time to reach
> completion and nothing is usable before it's completed. Thus there is
> the risk of burn out for contributors.
>
> I fully agree with this.


> Going from one version to the next instead is easier and takes less
> time. Thus we see commits to HEAD more often and it's a good motivation
> and a good image for end users. The downsides are it probably takes more
> time to reach the last version compared to a direct big jump, and
> contributors are mainly interested by the GPU they own (which is
> logical). So people owning the very latest hardware won't contribute
> before the support for their computer is being worked on. And others may
> stop to contribute once their GPU is supported.
> --
> Jean-Sébastien Pédron
>
> Yes, your are right.

When someone see, that there are a lot of commits done to the driver,
it could motivate them to contribute to it.

Also I see, that the file-by-file strategy could maybe end up in a mess.
The Problem I see, is that the understanding of the code would be very hard,
also when someone cancel his support, it would be hard to catch up with the
port of the code.

Another big issue would be the debugging, it's easier to debug small steps,
that
big ones.

So I would prefer the commit-by-commit strategy.

On 29 December 2015 at 22:21, Bertram Scharpf <lists at bertram-scharpf.de>
wrote:

> Hi,
>
> On Monday, 28. Dec 2015, 18:36:26 +0100, Jean-Sébastien Pédron wrote:
> > My proposal is that we continue to work on GitHub, namely in:
> > https://github.com/freebsd/freebsd-base-graphics
> >
> > [...]
> >
> > 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.
>
> 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
>
> --
> Bertram Scharpf
> Stuttgart, Deutschland/Germany
> http://www.bertram-scharpf.de
> _______________________________________________
> freebsd-x11 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscribe at freebsd.org"
>