Now, with WiringPI being an archived and unmaintained library, and the deprecation of the sysfs interface since Kernel 4.8, the official method for GPIO access from user space is using the character device /dev/gpiochip* with the libgpiod library.
However, there is currently no snap interface for the usage of character devices, despite ongoing efforts discussed here and reported in this bug which suggests the usage of gpio aggregator. It seems there is no specific snap interface for the character device, but it’s possible to use the system-files interface, as shown in this PR, allowing straightforward access:
After a quick look, I couldn’t find any interface that better fits this situation. Thus, I’ll be happy to support the use system-files for the time being.
+1 for granting auto-connection for this system-files request
@reviewers I’m not sure about the naming convention for the plug in this concrete situation. I may be happy as it is, but I would like to know your opinion
That said, using /dev/gpiochip0 looks pretty hardware specific (of course the name suggest that the target of this application is Rpi, but still…) and I would suggest to move the gpio-aggregator as soon as it will be released
system-files should/cannot be used to access /dev/* devices, as it stops working as soon as another interface accessing /dev/* is used at the same time*. custom-device should be used instead.
this is a quirk, we are considering making the behavior consistent for UC24 so that this never works, as custom-device exists now
Regarding the custom-device interface, would it also work for the /sys/devices/platform/soc/fe200000.gpio/gpiochip0/dev file?
Additionally, the address fe200000 is specific to the Raspberry Pi 4 Model B. We would require a wildcard to include other RPi models. However, since wildcards are not allowed yet (please correct me if I’m wrong), we are creating a list with the necessary files for each 64-bit model.
yes, it works assuming the store gives permission which means the use is justifiable, as the interface slots are superprivileged, we should support already defining them on an app, that app will need a matching plug that gets self-auto-connected.
We would require a wildcard to include other RPi models. However, since wildcards are not allowed yet .
We have been asked before to lift that restriction. Technically it’s possible. The main issue is that reviewers need to be careful that those wildcards are not too broad, and to setup the snap-declaration correctly.
Yeah, you could always do this but we did set up a policy to not allow it at all (your upload would have been rejected) … seems we here have an exception now