From: Kent Gibson <warthog618@gmail.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: linux-gpio@vger.kernel.org
Subject: Re: [libgpiod][PATCH 0/4] dedicated examples
Date: Thu, 15 Jun 2023 23:39:47 +0800 [thread overview]
Message-ID: <ZIsww5gkT0dVYvSb@sol> (raw)
In-Reply-To: <CAMRc=MdqZtqnBuMjGLKo6FOSfAAanGsYu9aAWiZuhnTgzEVaDA@mail.gmail.com>
On Thu, Jun 15, 2023 at 05:16:04PM +0200, Bartosz Golaszewski wrote:
> On Wed, Jun 14, 2023 at 6:00 PM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > The C ones are specifically for simple sysfs-like equivalence, as telling
> > users they need to replace a single write to a file with ~100 lines of C
> > is really hard to sell.
>
> You don't really need 100 LOC for a trivial request in C (it's a bit
> over-dramatic :) ) but my thinking is: whether it's 5 lines or 10 or
> 100 - it doesn't change the fact that it is a fundamental change from
> sysfs in that you need to write the code, compile it, link it against
> the right libraries etc. etc. It will be so much more work no matter
> how much you simplify the API and that is already enough to scare away
> a lot of folks used to just writing to a bunch of files.
>
Sure - those using scripts would probably go for Python anyway.
But no one in their right mind would elect to use the C API given the
alternatives, which makes it basically pointless.
> This is why I'm proposing the DBus API as a way of replacing several
> features of sysfs that are so beloved by users: central authority over
> GPIOs, easy to use from shell scripts (just replace "echo 223 >
> export; echo output > 223/direction" etc. with "gdbus call --system
> --dest io.gpiod1 --object-path /io/gpiod1/gpiochip2 --method
> io.gpiod1.Chip.RequestLines <args>" which is just a tiny bit more
> verbose but achieves the same goal and exposes all uAPI v2 features)
> and only requires including the dbus daemon in your system which would
> be packaged by most distros shipping libgpiod eventually. DBus has the
> advantage of being usable from any language you fancy and still being
> relatively fast.
>
> In other words, I'm thinking that packing a lot of "helper" features
> into libgpiod will only lead to feature creep but not achieve the goal
> of pulling people away from sysfs.
>
And you think I'm exaggerating.
Removing a few pain points is not "packing a lot of "helper" features".
Cheers,
Kent.
prev parent reply other threads:[~2023-06-15 15:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-14 3:54 [libgpiod][PATCH 0/4] dedicated examples Kent Gibson
2023-06-14 3:54 ` [libgpiod][PATCH 1/4] core: examples: add " Kent Gibson
2023-06-14 3:54 ` [libgpiod][PATCH 2/4] bindings: cxx: " Kent Gibson
2023-06-14 3:54 ` [libgpiod][PATCH 3/4] bindings: python: " Kent Gibson
2023-06-14 3:54 ` [libgpiod][PATCH 4/4] bindings: rust: " Kent Gibson
2023-06-14 7:52 ` Erik Schilling
2023-06-14 8:18 ` Kent Gibson
2023-06-14 8:29 ` Erik Schilling
2023-06-14 13:03 ` [libgpiod][PATCH 0/4] " Bartosz Golaszewski
2023-06-14 13:21 ` Kent Gibson
2023-06-14 13:26 ` Bartosz Golaszewski
2023-06-14 13:57 ` Kent Gibson
2023-06-14 15:11 ` Bartosz Golaszewski
2023-06-14 16:00 ` Kent Gibson
2023-06-15 15:16 ` Bartosz Golaszewski
2023-06-15 15:39 ` Kent Gibson [this message]
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=ZIsww5gkT0dVYvSb@sol \
--to=warthog618@gmail.com \
--cc=brgl@bgdev.pl \
--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).