Contributing to the kernel video drivers

[Jean-Sébastien Pédron]

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.

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.

So I'm not sure what is the best path. I tend to prefer the one Linux
version at a time, but I'm open to suggestions. We could also try both
if enough people are interested in: a team works on 3.9, another team on
4.3.

> Am I the only one with the impression that FreeBSD is so way behind
> just because of this approach?

Currently, we don't have a real method, we mainly lacked dedicated
maintainer(s). I'm the only one working on Radeon and took on i915
recently. As I'm doing this on my spare time, progress is slow and we
have a lot to catch.

What took time here is that our DRM didn't match a particular version of
Linux, so it was difficult to bring patches. That's why I went with the
file-by-file approach. I think it worked well, but this is costly.

> 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?

The Linux shim should handle most of this. If sed would work, then a
wrapper will work too.

Then, for things where we can't add a wrapper, like I²C or calls in the
VM, it must be changed manually because the code must be studied first.

-- 
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/92551728/attachment.sig>