Re: [libgpiod][PATCH] tools: port the test-suite to using gpio-sim

[Kent Gibson <warthog618@xxxxxxxxx>]

On Fri, Feb 18, 2022 at 10:22:49AM +0100, Bartosz Golaszewski wrote:
> On Thu, Feb 17, 2022 at 2:50 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> >
> > On Wed, Feb 16, 2022 at 04:05:12PM +0100, Bartosz Golaszewski wrote:
> > > This makes the gpio-tools tests use the gpio-sim kernel module instead
> > > of the old gpio-mockup.
> > >
> >
> > I have a problem with unconditionally switching the tests to gpiosim as
> > that restricts building and running libgpiod tests to kernel v5.17 or
> > later.
> > That is fine for v2, but v1 is effectively legacy and so tests should
> > still build and run on legacy kernels.
> >
> 
> v1 is going to be supported for an indefinite period of time in the
> v1.6.x branch. The master branch is moving forward though. I'm
> applying changes that can go into v2 already to master and the big API
> change is still WIP so it's kept in the next/libgpiod-2.0 branch.
> 
> Only master will get this patch, not v1.6.x - it keeps using
> gpio-mockup because users depend on it - for instance
> meta-openembedded has a ptest package running the libgpiod tests based
> on gpio-mockup.

Oh, ok.  I was thinking [libgpiod] patches applied to the v1 branch and
[libgpiod v2] applied to v2. And that any common improvements, so
[libgpiod] patches that don't conflict with v2, would also be applied to v2.

That still makes sense to me, btw, as otherwise you get patches like this
where is it unclear if it is meant for master or v1.6.x.
Or is there another prefix for legacy?

> 
> > What is the benefit of the switch (other than exercising gpiosim)?
> >
> 
> So this conversion is pretty much one-to-one for now but just like the
> core C tests - gpio-sim will enable us to drop using gpioset when
> testing gpioget for instance (we can use hogs but I need to add this).
> We can also have gaps in line names etc.
> 

Fair enough.  I'm tempted to argue whether those improvements would actually
improve overall test coverage, but it certainly is more flexible and nicer
to use than mockup.
And I notice the tests also run faster as they doesn't have to do the mockup
module loading.  Yay.

Cheers,
Kent.