Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"preserve" option removed for GPIO direction #42

Open
ARizzo35 opened this issue Jul 17, 2020 · 2 comments
Open

"preserve" option removed for GPIO direction #42

ARizzo35 opened this issue Jul 17, 2020 · 2 comments
Labels

Comments

@ARizzo35
Copy link

Why was the "preserve" option removed for GPIO direction? Seems to have happened on this commit: 49664e0

@vsergeev
Copy link
Owner

vsergeev commented Jul 23, 2020

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
Copy link

orgua commented Jul 30, 2020

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants