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.