[igt-dev] [PATCH i-g-t 00/30] Add FreeBSD Support

[Petri Latvala]

On Thu, Dec 12, 2019 at 10:20:29AM -0800, D Scott Phillips wrote:
> Jani Nikula <jani.nikula at linux.intel.com> writes:
> 
> > I'll mostly defer to Petri and Arek, the IGT maintainers, on the
> > details.
> >
> > I think the bigger questions are, 1) How do we ensure this does not
> > bitrot in a matter of weeks? Which translates to, 2) Who is going to
> > automate and maintain continuous build testing? And, 3) Who's going to
> > take ownership of the port in general?
> >
> > Personally, I don't think this is going to work long term just by
> > merging the port upstream. I think without the continuous support from
> > people who care about FreeBSD, this is going to be a net negative.
> 
> Right, I think that's a fair point. What level of continuous support do
> you think would get us out of the negative here? A continuous build
> could be fairly easy to get configured, but might be a side workflow
> apart from how normal CI results are presented. I think that could be a
> reasonable indication that things aren't rotting. More sophisticated CI
> is within the realm of possibility but could be quite a bit harder to
> get off the ground with.

I'd say the bar to reach is

* build-testing for each commit
* someone responsible for fixing issues in the above in a timely manner

Build-testing we can reach quite easily in gitlab, for some values of
easily, but the second point is harder.

> Ultimately, I think as long as the kernel driver port exists this is
> something that we will want.

Yep. Ultimately, running the tests on HW on FreeBSD is a change that I
would very much welcome.

> As to who owns the port, FreeBSD has a "Graphics Team" that collectively
> owns the kernel driver port, so I think the most robust answer going
> forward is to have them own this port. I can take this up with them and 
> see if they'll affirm that they will take some ownership here.

Thanks for doing this!

As for the series as such:

There's some trivial cleanups in there that I suspect will help even
Linux users on non-glibc systems that we can merge as is. I'm going to
go through reviewing the series later this week for those parts.

The null-implementation patches are for sure getting a NAK in that
form. They need a function-by-function analysis of whether the correct
"do nothing" approach is actually doing nothing or straight up
igt_skip("Not supported on this platform"); in some form.
For example, tests that use igt_fork_signal_helper will test nothing
if they don't manage to fork a periodical interrupter process.


-- 
Petri Latvala