On Tue, Oct 30, 2018 at 01:45:29PM +0100, Linus Walleij wrote: > On Thu, Oct 18, 2018 at 9:16 PM Uwe Kleine-König > <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > > [Bartosz] > > > I do believe that having a single driver will cause less confusion in > > > the future and make it less likely that someone needing another > > > testing future will try to get merged a third separate driver. Linus > > > will have the last word of course but personally I'd like to work > > > towards extending gpio-mockup. > > > > I won't argue here. Iff you think gpio-simulator is good to take without > > merging with gpio-mockup I'm willing to work on the (other) identified > > weaknesses. > > We just don't want to have to maintain two synthetic drivers for this. > > libgpiod has an extensive set of tests: > https://github.com/brgl/libgpiod/tree/master/tests > > If gpio-simulator should replace gpio-mockup, all it needs to do > is pass all these tests without changes. That is the beauty of > test driven development. Just from a quick glance, it won't be able to pass without modifications (which I think should be fine). The place that won't work is event_worker() which hardcodes some things specific to the mockup driver (i.e. the sysfs path). > However I would have a serious allergic reaction to any > "merge this now fix any tests later" or "not my problem to > pass these tests" approach. I agree here. gpio-mockup shouldn't be deleted if that breaks libgpiod. > A slot-in replacement doing all that gpio-mockup does and then some > would likely be accepted on the condition that gpio-mockup is deleted > at the same time, as that would prove it is a bigger and better swiss > army knife for GPIO simulation/mockuping. Not sure I find the time to work on this in the near future. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |
