From: Kent Gibson <warthog618@gmail.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: "Jiří Prchal" <jiri.prchal@aksignal.cz>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
"Bartosz Golaszewski" <brgl@bgdev.pl>
Subject: Re: [libgpiod] feature request: output state read and sustain
Date: Wed, 29 Jun 2022 19:20:22 +0800 [thread overview]
Message-ID: <20220629112022.GA30306@sol> (raw)
In-Reply-To: <CAHp75Ve5zpwgc9kk06LYJU8GveXFdgbgyyxXoQm0dy_OiLTF2Q@mail.gmail.com>
On Wed, Jun 29, 2022 at 12:58:18PM +0200, Andy Shevchenko wrote:
> On Wed, Jun 29, 2022 at 12:48 PM Kent Gibson <warthog618@gmail.com> 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@aksignal.cz> 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
> 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.
>
I don't think it is what you think it is.
Take a look. If you don't like it then get Bart to bin it.
There was no on-list discussion. I had preliminary disussions with Bart,
and had intended to float it as an RFC, but got distracted by other
things and ended up going direct to an implementation.
Last I heard the DBus daemon is still on the cards, but not sure where
Bart is with it, and the gpioset addition is for simpler cases where
DBus is overkill or where there is no daemon.
It is not the default behaviour, it is an optional mode.
gpioset maintains the context, not shell.
"User's forgetting" is language independent. Shell scripts matter!
What else have I missed replying to? I don't know.
And good to see our apparent agreement in the previous mails was just an
aberation. I was starting to think there was something wrong with the
universe :-|.
Cheers,
Kent.
next prev parent reply other threads:[~2022-06-29 11:20 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-25 10:02 [libgpiod] bug: pull-up does not work Jiří Prchal
2022-03-25 14:57 ` Kent Gibson
2022-03-25 15:13 ` Jiří Prchal
2022-03-25 16:01 ` Kent Gibson
2022-03-28 7:12 ` Jiří Prchal
2022-03-28 8:08 ` Kent Gibson
2022-03-28 8:58 ` Jiří Prchal
2022-03-28 9:56 ` Kent Gibson
2022-06-28 13:08 ` [libgpiod] feature request: output state read and sustain Jiří Prchal
2022-06-29 7:23 ` Kent Gibson
2022-06-29 9:25 ` Jiří Prchal
2022-06-29 10:10 ` Kent Gibson
2022-06-29 10:27 ` Andy Shevchenko
2022-06-29 10:47 ` Kent Gibson
2022-06-29 10:58 ` Andy Shevchenko
2022-06-29 11:20 ` Kent Gibson [this message]
2022-06-29 11:55 ` Andy Shevchenko
2022-06-29 12:56 ` Bartosz Golaszewski
2022-06-29 15:22 ` Andy Shevchenko
2022-06-29 11:17 ` Jiří Prchal
2022-06-29 11:25 ` Kent Gibson
2022-06-29 11:48 ` Jiří Prchal
2022-06-29 12:51 ` Kent Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220629112022.GA30306@sol \
--to=warthog618@gmail.com \
--cc=andy.shevchenko@gmail.com \
--cc=brgl@bgdev.pl \
--cc=jiri.prchal@aksignal.cz \
--cc=linux-gpio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).