search

vsergeev / python-periphery

A pure Python 2/3 library for peripheral I/O (GPIO, LED, PWM, SPI, I2C, MMIO, Serial) in Linux.
MIT License
519 stars 139 forks source link

"preserve" option removed for GPIO direction #42

Open ARizzo35 opened 4 years ago

ARizzo35 commented 4 years ago

Why was the "preserve" option removed for GPIO direction? Seems to have happened on this commit: https://github.com/vsergeev/python-periphery/commit/49664e032649c1b8f3af0bf91f4bea4ae4e08f9b

vsergeev commented 4 years ago

The option was removed for the v2.0.0 release, which introduced character device GPIOs and reshaped the GPIO API around them. The major version number change from 1 to 2 is largely due to breaking changes like this in the GPIO API.

Character device GPIOs behave somewhat differently from sysfs GPIOs. They lose their direction and value state on close, so they can't implement a "preserve" direction option. In order to have consistent behavior between the two, sysfs GPIOs were changed to be unexported on close. This limits the use of the "preserve" direction exclusively to situations where the sysfs GPIO was exported externally before it was opened by python-periphery, and this vestige did not seem worth supporting in the API when sysfs GPIOs are now deprecated and the future is character device GPIOs.

In addition, there were complaints early on (#11, #23) about GPIOs not being unexported on close. In some situations, not unexporting the GPIO on close could be interpreted as a resource leak, and in others, it's a convenient way to retain direction/value state after the program is closed. I'm sympathetic to both use cases for sysfs GPIOs, but with character device GPIOs there is no longer any ambiguity, as they are always unexported on close.

In summary, there are a handful of trade-offs in the consistency of behavior between sysfs GPIO and character device GPIOs, contaminating the GPIO API with sysfs-only options, and ambiguity about whether or not sysfs GPIOs should be unexported on close.

Feel free to chime in if you have any thoughts one way or another.

orgua commented 3 years ago

@ARizzo35 i feel you. i would love to see the previous interface getting still supported. wouldn't it be possible to allow both? Maybe with a different function-name?