Skip to content

Request: Replace sysfs-gpio with gpio-cdev #20

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

Closed
drinkdhmo opened this issue May 27, 2019 · 4 comments
Closed

Request: Replace sysfs-gpio with gpio-cdev #20

drinkdhmo opened this issue May 27, 2019 · 4 comments

Comments

@drinkdhmo
Copy link

Since sysfs is now deprecated, we should migrate dependence to gpio-cdev.

@posborne
Copy link
Member

While deprecated, the reality in the field is that there are still kernels being deployed that do not yet have support for gpio-cdev. This is increasingly changing but I wanted to provide that perspective. I believe the last of the major changes to the cdev userspace ABI landed in 4.8. With 4.9 LTS kernel being common for newer projects it might be safe to start pushing cdev. There will be people running existing devices on older kernels, however, and jumping might leave those people in the cold.

That being said, for what the embedded-hal project is, I think moving to gpio-cdev (which I will revisit placing under wg maintainership) in the next half year probably makes sense and is the right move as kernels.

@ryankurte
Copy link
Contributor

i was wondering about this too.
i think switching to cdev is the right move, but perhaps given the long tail of kernels for embedded hardware it might be worth including both with a feature flag or something to regress?

@RandomInsano
Copy link

RandomInsano commented Jun 2, 2019 via email

@ryankurte
Copy link
Contributor

howdy, we have deployed feature flags to switch between implementations in v0.3.0 and provide both in v0.4.0-alpha.X (with feature-flags to disable each as required).

so i think we can close this, thanks folks! we don't (at the moment) have a way to automagically choose at runtime, but if there is a need for this behaviour we can open a new issue / PR.

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

No branches or pull requests

4 participants