All of lore.kernel.org
 help / color / mirror / Atom feed
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.


      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 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.