Just to clarify what I'm doing here:
The goal for GPIO support in native is two-fold:
- accelerate application development without hardware (a virtual GPIO interface is also part of the PR)
- accelerate driver development for GPIO attached devices by providing access to hardware connected to the host system
The incentive is that a raspberry pi or similar can act as a cheap development board when the target board is not (yet) available, and the possibility to use Valgrind et al for driver development.
In the long run, the virtual interface should provide a means for test automation (of distributed applications in virtual testbeds) while it immediately allows for manual testing (again, with Valgrind et al).
It is not a goal to have the best solution for production use of GPIO devices, as native is meant as a development tool.
I2C (SPI, PWM, ...) is a different matter and on the to do list for the same reasons as GPIO.
Apparently there is at least one other method of interfacing GPIO as well, some broadcom driver which can be accessed from user space and is said to be faster. I'm not sure whether it makes sense to support this as in addition to the sysfs approach.