| Message ID | 20230614035426.15097-1-warthog618@gmail.com |
|---|---|
| Headers | show |
| Series | dedicated examples | expand |
On Wed, Jun 14, 2023 at 6:00 PM Kent Gibson <warthog618@gmail.com> wrote: > > On Wed, Jun 14, 2023 at 05:11:32PM +0200, Bartosz Golaszewski wrote: > > On Wed, Jun 14, 2023 at 3:57 PM Kent Gibson <warthog618@gmail.com> wrote: > > > > > > Any functionality to add to libgpiod? > > > > > > > I don't think so at the moment. Do you see anything obvious? I know, > > we spoke about putting the line resolver into libgpiod but I'm not > > sure we really want it. At least in the core library anyway. The GLib > > layer on top of libgpiod is a place that would be a good target for > > such a functionality IMO. > > > > Yeah, making the line resolver generally available is a can of worms. > Not prepared to take that one on at the moment. > I'm reasonably content to leave that to the user - as long as they can > readily iterate over the chips and lines themselves. > Maybe provide an iterator for all the lines in the system > available to the user? > > > Other than that, I think libgpiod now has everything it needs to cover > > all use-cases for the uAPI. > > > > The point isn't that coverage is missing, it is to find ways to make > common tasks simpler. > > The ones that spring to mind so far are: > - C: requesting a single line as output > - C: requesting a single line as input > - providing a toggle function for line_value, as it is an enum which is > a bit awkward. > - the chip iterator in the python tools helpers.py > - streaming operators for the enums where they are not automatically > provided > > > 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. 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. Bart > The config options would be as minimal as possible. > I was going to suggest the user could always reconfigure the line later > if they need extra features, but there is no function to return the > existing line config :-(. > > Cheers, > Kent.