Re: [libgpiod][PATCH] tools: gpiomon: add timeout option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 30, 2023 at 3:09 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
>
> On Tue, May 30, 2023 at 02:21:18PM +0300, andy.shevchenko@xxxxxxxxx wrote:
> > Tue, May 30, 2023 at 05:29:23PM +0800, Kent Gibson kirjoitti:
> > > On Mon, May 29, 2023 at 08:20:44PM +0000, Gabriel Matni wrote:
> > > > From: Gabriel Matni <gabriel.matni@xxxxxxxx>
> >
> > ...
> >
> > > My preferred solution is to run gpiomon as a coproc and have the
> > > controlling script perform the timeout. e.g.
> > >
> > > #!/bin/env bash
> >
> > Oh, this is too bad.
> >
> > > coproc gpiomon "$@"
> > > while :
> > > do
> > >         read -t5 -u ${COPROC[0]} event || break
> > >         echo $event
> > > done
> > > kill $COPROC_PID
> >
> > I'm wondering what coproc is and why it requires bash.
> >
>
> And I'm wondering why your mail got to the list, but not to me directly,
> despite being directly addressed.  It isn't even in my junk folder.
> And it was gmail to gmail.  Now that is weird.
>
> Anyway, coproc is a feature of many shells, such as bash, zsh, ksh.
> I don't think or ash or dash have coproc, but then you cn always use named
> pipes to similar effect.  It would be similar to the simple gpioset
> daemon I posted the other day, just in reverse.
>
> I did say that coproc was my preferred solution, not that it is the only
> one.
>
> > What I want to have and keep that working is that all our tools can be run in
> > Busybox environment (embedded application). That's why I'm against seeing bash
> > in any form of the tooling.
> >
>
> It isn't IN the tooling.  It is in the shell that calls the tooling.
> The tool test suite does require bash, but that is due to the framework we
> use, not coproc.
>
> I take it you would be in favour of an idle timeout option then?
>
> I'm puzzled why no one has ever asked for it before, if it is something
> that is in demand.
>
> Cheers,
> Kent.

I do see value in this option. I'm not buying the argument about
losing events - the same can be said in reverse - before we even
request a line, we can lose events too.

Gabriel: please address the issues pointed out by Kent if you still
want to add this.

Bart




[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux