gpio-manager D-Bus service support

[dlech]

Description

Add support for controlling GPIOs via the gpio-manager D-Bus service.

There have been many attempts to use the gpio character device interface in labgrid since the sysfs interface is deprecated and is turned off in some kernel builds. However, these were rejected because the state of the gpio can change when the character device closes.

The gpio-manager D-Bus daemon is supposed to be the "new" way to address this. It has been around for a few years, but isn't widely available yet. I suspect that will change though. And it is fairly simple to install from source if needed (some notes).

I have tested this locally using the examples for both local and remote usage (slightly customized to my gpiochip path and pin number). I haven't implemented the lookup by name part yet (I'll have to do that on a Rapsberry Pi, which will be slower). I'm just putting this out there to see what people think first before I polish it up the rest of the way.

Similar to the way the sysfs gpio implementation will export gpios that are not already exported, this will request gpios that are not already requested. Since there isn't a process managing this, it means the line will stay requested until the user manually releases the request, e.g using the gpiocli command line too.

Checklist

• Documentation for the feature
• Tests for the feature (There are a couple of tests already, but they don't cover everything. It is hard to have tests for something that requires real hardware. I opened Use umockdev for better code coverage #1820 to discuss a solution, but I consider that out of scope for this PR.)

• The arguments and description in doc/configuration.rst have been updated

• Add a section on how to use the feature to doc/usage.rst

• PR has been tested

• Man pages have been regenerated

[dlech]

Hmm... OK, I missed the previous discussions on why character device support wasn't added before. It looks like I need to update this to use the D-Bus API so that we get persistent state, e.g. even after the agent exits.

https://libgpiod.readthedocs.io/en/latest/dbus.html

[dlech]

• Ideally, when labgrid-exporter is started, it would open the character device and claim the pins so that other applications could not use them (until labgrid-exporter exits). With the agent, a new process is run every time we access the GPIO remotely, so there is nothing to hold a claim on it.

I guess there is a problem that there isn't always an exporter (i.e. running locally), so even if the exporter process could hold open the gpiod file descriptor, it wouldn't solve the issue in all cases.

[dlech]

OK, I've updated this to use the D-Bus service, so should be worth a look now. I edited the first comment with the updated description.

[codecov]

Codecov Report

❌ Patch coverage is 42.01183% with 98 lines in your changes missing coverage. Please review.
✅ Project coverage is 45.2%. Comparing base (b94e172) to head (8d096d3).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
labgrid/util/agents/managed_gpio.py	43.7%	54 Missing ⚠️
labgrid/remote/exporter.py	0.0%	16 Missing ⚠️
labgrid/driver/gpiodriver.py	38.8%	11 Missing ⚠️
labgrid/resource/udev.py	47.0%	9 Missing ⚠️
labgrid/remote/client.py	0.0%	4 Missing ⚠️
labgrid/resource/remote.py	80.0%	2 Missing ⚠️
labgrid/resource/suggest.py	0.0%	2 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##           master   #1818     +/-   ##
========================================
- Coverage    45.2%   45.2%   -0.1%     
========================================
  Files         174     175      +1     
  Lines       13752   13905    +153     
========================================
+ Hits         6224    6291     +67     
- Misses       7528    7614     +86     

Flag	Coverage Δ
3.10	45.2% <42.0%> (-0.1%)	⬇️
3.11	45.2% <42.0%> (-0.1%)	⬇️
3.12	45.2% <42.0%> (-0.1%)	⬇️
3.13	45.2% <42.0%> (-0.1%)	⬇️
3.14	45.2% <41.6%> (-0.1%)	⬇️
3.9	45.2% <41.6%> (-0.1%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jluebbe]

This is quite a lot of new code and adds a new dependency on jeepney on the agent/exporter side.

Which benefits do you see compared to adding support for the new per-chip sysfs GPIO interface (which is not deprecated; see also #1715 (comment)) to the existing GpioDigitalOutputDriver? It should be possible to implement it in a fully backwards compatible way.

[dlech]

Which benefits do you see compared to adding support for the new per-chip sysfs GPIO interface (which is not deprecated

I was not aware of this. So perhaps there is not much benefit.

It could still be interesting to people who are already using gpio-manager/gpiocli though.

Although, I suppose one could easily create an HTTP server that talks to gpio-manager and use HttpDigitalOutput instead, which would be more efficient than the agent way of doing things.