[Intel-gfx] FreeBSD i915 driver update

Daniel Vetter daniel at ffwll.ch
Tue May 17 10:23:22 UTC 2016


On Fri, May 13, 2016 at 10:34:59AM +0300, Jani Nikula wrote:
> On Fri, 13 May 2016, Scott Long <scottl at netflix.com> wrote:
> > Jean-Sébastien and other developers have been discussing a new approach
> > for post-3.8.13 updates. Instead of maintaining a large set of changes,
> > the plan is to keep the driver as close as possible to the upstream Linux
> > version, and use straightforward shims to adapt to interfaces provided by
> > FreeBSD where possible.
> 
> FWIW, I think this is likely the only viable option.
> 
> The i915 driver is a fast moving target, and I have witnessed the
> struggles of full time paid developers backporting and forward porting
> drm and i915 features from Linux kernel version to another. It is not a
> trivial task. Last I checked, the Linux driver backports project has
> also given up backporting latest drm drivers to stable kernel versions.
> 
> I don't have any FreeBSD experience and I don't know what kind of team
> of developers you have, but it is my educated guess that you'll have
> plenty of more productive things to do than trying to maintain a
> significant amount of delta with upstream while also trying to stay
> up-to-date.
> 
> > Our ultimate goal is to align closely with the Linux graphics
> > development community and collaborate with Intel, ATI, and others on
> > keeping FreeBSD up to date in their product development efforts.
> 
> The focus and priority of the i915 driver is obviously Linux, but I
> don't see us rejecting patches that help FreeBSD if the patches
> generally make sense and don't interfere with the main priority.

What I don't really like is the old approach of trying to abstract away
differences between Linux and *BSD in drmP.h with some screaming macros.
Given the imbalance of manpower between Linux and *BSD I think the best
(and probably only really) approach is to have linux compat types and
wrapper functions for everything. Which seems to be the new plan.

If there's stuff needed above&beyond that I think we need to look at in on
a case-by-case basis and figure out what makes sense. For me the crucial
bit isn't so much whether we need to make changes in upstream linux or
not, but whether there's a benefit for usptream too. If bug reports and
bugfixes flow back to linux, then I'm all for it. If it's a one-way street
then frankly I don't care ;-)

> Good luck with your efforts!

Yeah, would be great to have *BSD tracking upstream closely again, wish
you the best with that!

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list