Re: [libgpiod v2][PATCH v3 4/5] tools: add gpiowatch

[Kent Gibson <warthog618@xxxxxxxxx>]

On Tue, Nov 08, 2022 at 07:04:36PM +0100, Bartosz Golaszewski wrote:
> On Tue, Nov 8, 2022 at 4:38 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> >
> > On Tue, Nov 08, 2022 at 04:00:08PM +0100, Bartosz Golaszewski wrote:
> > > On Tue, Oct 11, 2022 at 2:29 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > > >
> > > > Add a gpiowatch tool, based on gpiomon, to report line info change
> > > > events read from chip file descriptors.
> > > >
> > > > Inspired by the gpio-watch tool in the linux kernel, but with gpiomon
> > > > features such as custom formatted output, filtering events of
> > > > interest and exiting after a number of events, so more useful for
> > > > scripting.
> > > >
> > > > Default output is minimalist, so just time, event type and line id.
> > > > Full event details are available using the custom formatted output.
> > > >
> > > > Signed-off-by: Kent Gibson <warthog618@xxxxxxxxx>
> > > > ---
> > > >
> > > > Changes v2 -> v3:
> > > >    - Minimise the default output to more closely match gpiomon.
> > > >    - Add --format option for when more detail is required.
> > > >    - Add --num-events option to exit after a number of events.
> > > >    - Add --event option to report only specific event types.
> > > >    - Add --quiet option to not print events.
> > > >    - fix monotonic to realtime conversion on 32 bit platforms.
> > > >
> > >
> > > Nice and clean, I don't have any issues other than the regular
> > > coding-style bikeshedding.
> > >
> >
> > Will be renamed to gpionotify for v5, ok?
> 
> Yes, sure, just like discussed.
> 
> >
> > > What happened to the idea we've been floating about creating a single,
> > > busyboxy executable with links rather than separate executables? Have
> > > we ever agreed on it?
> > >
> >
> > Yeah, last we spoke on it we agreed it was of dubious value and a low
> > priority, so I didn't go anywhere with it.  You've reconsidered?
> >
> 
> I'm seeing that the tools-common.c file grew quite a bit after your
> rework (which is good, a lot of stuff has been generalized) which
> makes me think it wouldn't be a bad idea to not include it 6 times
> separately. It's either a libgpio-tools or putting this stuff into the
> same executable?
> 

Fair enough - for some reason I was thinking tools-common did get linked
into a libgpiod-tools lib, but I guess not.

The bulk of the rework is the resolver, and I was thinking that some
form of that should go in core libgpiod - that would also reduce the
duplication problem.

> Anyway, we can do it later.
> 

Agreed - not for this series.

Cheers,
Kent.