From: Zev Weiss <zweiss@equinix.com>
To: Joel Stanley <joel@jms.id.au>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>,
Andrew Jeffery <andrew@aj.id.au>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
OpenBMC Maillist <openbmc@lists.ozlabs.org>,
Eddie James <eajames@linux.ibm.com>
Subject: Re: [libgpiod PATCH] gpioget: Add --line-name to lookup GPIO line
Date: Fri, 3 Dec 2021 03:50:19 +0000 [thread overview]
Message-ID: <20211203035019.GC25091@packtop> (raw)
In-Reply-To: <CACPK8XcEhsz8Xk2m7bdPaFnwQ3BrKTH80r-ir_qwngTZ+FmGBQ@mail.gmail.com>
On Wed, Dec 01, 2021 at 08:29:47PM PST, Joel Stanley wrote:
>On Wed, 1 Dec 2021 at 08:29, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>
>> On Wed, Dec 1, 2021 at 8:29 AM Joel Stanley <joel@jms.id.au> wrote:
>> >
>> > Systems provide line names to make using GPIOs easier for userspace. Use
>> > this feature to make the tools user friendly by adding the ability to
>> > show the state of a named line.
>> >
>> > $ gpioget --line-name power-chassis-good
>> > 1
>> >
>> > $ gpioget -L pcieslot-power
>> > 0
>
>> I'm not very convinced to be honest. It's not like "gpioget gpiochip0
>> `gpiofind gpiochip0 line-name`" requires much more typing than
>> "gpioget gpiochip --line-name=name".
>
>I'm taking on feedback from people working in our labs, and
>implementing userspace applications. We've been building BMCs with
>mainline Linux for about six years now, and it's been a long road
>re-training them from "back in the day we just did devmem <this>
><that>" and "why can't we just do cat /sys/class/gpio/gpio305/value",
>and now "why does the level of the GPIO change back after I run the
>command?".
>
>This usability improvement is one more step towards them using and
>being happy with the "new world" of the gpiod API.
>
>Once we settle on a good API here, I plan on submitting a version of
>gpioget/gpioset added to busybox.
>
>> There are also other questions:
>> this uses getopt and only allows to specify a single line name. What
>> if we want to specify more lines like with offsets? Even if you allow
>> multiple names, getopt() doesn't guarantee ordering of arguments.
>
>If you're happy with the concept I'm happy to iterate on the implementation.
>
>Yes, it only allows a single line name. That tends to be how the tool
>is used, both from the command line and in scripts.
>
>Can you give me an example of your proposed command line API, so I can
>understand what you're suggesting here?
>
My two cents: like Jeremy, I would very much welcome the ability to
specify GPIOs by name instead of number, but the one-line-only
limitation does seem unfortunate. How about making a command-line flag
that just means "line-specifier arguments should be interpreted as names
instead of numbers"?
So you could do:
$ gpioget --by-name chassis-intrusion cpu1-prochot
0 1
$ gpioset --by-name led-green=1 led-red=0
Zev
WARNING: multiple messages have this Message-ID (diff)
From: Zev Weiss <zweiss@equinix.com>
To: Joel Stanley <joel@jms.id.au>
Cc: Andrew Jeffery <andrew@aj.id.au>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Bartosz Golaszewski <brgl@bgdev.pl>,
Eddie James <eajames@linux.ibm.com>,
OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: [libgpiod PATCH] gpioget: Add --line-name to lookup GPIO line
Date: Fri, 3 Dec 2021 03:50:19 +0000 [thread overview]
Message-ID: <20211203035019.GC25091@packtop> (raw)
In-Reply-To: <CACPK8XcEhsz8Xk2m7bdPaFnwQ3BrKTH80r-ir_qwngTZ+FmGBQ@mail.gmail.com>
On Wed, Dec 01, 2021 at 08:29:47PM PST, Joel Stanley wrote:
>On Wed, 1 Dec 2021 at 08:29, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>
>> On Wed, Dec 1, 2021 at 8:29 AM Joel Stanley <joel@jms.id.au> wrote:
>> >
>> > Systems provide line names to make using GPIOs easier for userspace. Use
>> > this feature to make the tools user friendly by adding the ability to
>> > show the state of a named line.
>> >
>> > $ gpioget --line-name power-chassis-good
>> > 1
>> >
>> > $ gpioget -L pcieslot-power
>> > 0
>
>> I'm not very convinced to be honest. It's not like "gpioget gpiochip0
>> `gpiofind gpiochip0 line-name`" requires much more typing than
>> "gpioget gpiochip --line-name=name".
>
>I'm taking on feedback from people working in our labs, and
>implementing userspace applications. We've been building BMCs with
>mainline Linux for about six years now, and it's been a long road
>re-training them from "back in the day we just did devmem <this>
><that>" and "why can't we just do cat /sys/class/gpio/gpio305/value",
>and now "why does the level of the GPIO change back after I run the
>command?".
>
>This usability improvement is one more step towards them using and
>being happy with the "new world" of the gpiod API.
>
>Once we settle on a good API here, I plan on submitting a version of
>gpioget/gpioset added to busybox.
>
>> There are also other questions:
>> this uses getopt and only allows to specify a single line name. What
>> if we want to specify more lines like with offsets? Even if you allow
>> multiple names, getopt() doesn't guarantee ordering of arguments.
>
>If you're happy with the concept I'm happy to iterate on the implementation.
>
>Yes, it only allows a single line name. That tends to be how the tool
>is used, both from the command line and in scripts.
>
>Can you give me an example of your proposed command line API, so I can
>understand what you're suggesting here?
>
My two cents: like Jeremy, I would very much welcome the ability to
specify GPIOs by name instead of number, but the one-line-only
limitation does seem unfortunate. How about making a command-line flag
that just means "line-specifier arguments should be interpreted as names
instead of numbers"?
So you could do:
$ gpioget --by-name chassis-intrusion cpu1-prochot
0 1
$ gpioset --by-name led-green=1 led-red=0
Zev
next prev parent reply other threads:[~2021-12-03 4:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-01 7:29 [libgpiod PATCH] gpioget: Add --line-name to lookup GPIO line Joel Stanley
2021-12-01 7:29 ` Joel Stanley
2021-12-01 8:29 ` Bartosz Golaszewski
2021-12-01 8:29 ` Bartosz Golaszewski
2021-12-02 4:29 ` Joel Stanley
2021-12-02 4:29 ` Joel Stanley
2021-12-03 3:50 ` Zev Weiss [this message]
2021-12-03 3:50 ` Zev Weiss
2021-12-03 6:20 ` Andrew Jeffery
2021-12-03 6:20 ` Andrew Jeffery
2021-12-03 10:18 ` Bartosz Golaszewski
2021-12-03 10:18 ` Bartosz Golaszewski
2021-12-07 6:48 ` Joel Stanley
2021-12-07 6:48 ` Joel Stanley
2021-12-02 5:21 ` Jeremy Kerr
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=20211203035019.GC25091@packtop \
--to=zweiss@equinix.com \
--cc=andrew@aj.id.au \
--cc=brgl@bgdev.pl \
--cc=eajames@linux.ibm.com \
--cc=joel@jms.id.au \
--cc=linux-gpio@vger.kernel.org \
--cc=openbmc@lists.ozlabs.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.