Re: [libgpiod][PATCH 0/4] dedicated examples

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

 



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




[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