TimG wrote: ↑
Tue Jan 14, 2020 9:58 pm
It would be fantastic to see somebody pick up development of the WiringPi library. Of all the various GPIO libraries, WiringPi was especially easy to use -- even in shell scripts.
I don't know if it should be WiringPi but I think it would be great if there were a single recommended GPIO utility interfacing to something doing GPIO marshalling with a standardised API, with wrappers and libraries for the common languages, at least C, C++, Python, Scratch and perhaps even Assembler, with an equivalent available for Bare Metal use too.
Something comprehensive which has higher level support for specific hardware devices, extensible so devices can be easily created and added to that.
That may be something based on libgpio or wrapped around that, but, whatever it is, as easily usable and user friendly as the current libraries are.
It will face resistance, probably quite a lot, but removal of /dev/gpiomem would force access through a common API to the marshalling handler, allowing programs to be able to claim and use GPIO, while preventing programs using what other programs or OS are already using, accessing things they really shouldn't.
Not having that GPIO marshalling has always seemed a weak spot that goes against the philosophy of protecting the OS and programs from what anything else is doing. I can understand how and why it is, but I think it's time to do it better, and it's probably better to get a grip on that sooner rather than later.
I wouldn't want to lose WiringPi, RPI.GPIO, Zero.GPIO, gpio, raspi-gpio, pigpio and all the rest, because if people want to use those then so be it, but I think it would be better if they could all call the common API rather than doing it themselves.
And I know it's a big, fundamental change, but I believe it would be worth doing.