Re: [libgpiod] feature request: output state read and sustain

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

 



On Wed, Jun 29, 2022 at 2:56 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
>
> On Wed, Jun 29, 2022 at 12:58 PM Andy Shevchenko
> <andy.shevchenko@xxxxxxxxx> wrote:
> >
> > On Wed, Jun 29, 2022 at 12:48 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote:
> > > > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@xxxxxxxxxxx> wrote:
> >
> > ...
> >
> > > > Do not use shell. Use proper programming language that may give you an
> > > > easier way of handling this, i.e. _context_. Shell tools are
> > > > _context-less_ and here is the problem you are trying to solve, but
> > > > from the wrong end.
> > >
> > > Actually my proposed gpioset for v2 will support running interactively
> > > so it can maintain context and be driven from shell - for cases where
> > > basic scripting will suffice.
> >
> > Dunno if it's the right direction and if I missed any (additional) discussion.
> > As far as I remember the idea was to introduce DBus aware daemon that
> > should handle the context of the line and at the same time consider security
>
> And it's still very much on the roadmap.
>
> > implications. Allowing shell to be context-aware is a hidden mine
> > field. What will happen if the script/user forgets to move the line to
> > the proper state and the chip will drain a lot of current? So, at
> > least PM concerns just popped up immediately to my mind. What else can
> > be problematic? So, I dunno, it's a good idea to allow shell to leave
> > a line in some state when the user actually doesn't care about it
> > anymore. At the bare minimum this mustn't be default behaviour.
> >
>
> It's not much different from letting your current gpioset run in the
> background, is it?
>
> Kent just submitted his first version of gpioset, you can take a look
> at it and review it. :)

So far from Kent's and yours explanations there is no evidence to
raise an alarm.


-- 
With Best Regards,
Andy Shevchenko




[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