Switch to gpiocdev-rs for GPIO uAPI v2 support?

[eldruin]

Context: Our gpio-cdev crate only supports GPIO uAPI v1, which has been deprecated in the kernel. There is a new crate gpiocdev which does support it in newer kernels.

Preliminary analysis of switching to the newer gpiocdev in no particular order:

• Pro:
  • Supports GPIO uAPI v2 as well as v1 which is deprecated.
  • More active project.
  • Author is the author of the API in the Linux kernel.
  • gpiosim support.
• Cons:
  • Porting effort.
  • Adds many dependencies.
  • Breaking change.
  • Outside of the rust-embedded org.

See https://github.com/rust-embedded/gpio-cdev/issues/68

[fpagliughi]

I've been testing giocdev the last few days and am really impressed with what @warthog618 has done, especially with him claiming to be a Rust newcomer when he started the project!

And though I hate throwing away good work (including my own), I'm leaning toward moving my own apps to gpiocdev.

I also found some additional Pro's:

• Supports async/await for all the major executors via tokio and async-io
• The API is close to libgpiod, and makes it more convenient to switch between Rust and C/C++ project (which I am forced to do by some customers)
• The author seems extremely responsive and committed to the project.
• Now I won't need to do a lot of free work to get v2 and async-io implemented :-)

[warthog618]

If you have any doubts I was a Rust newbie you can always look at some of the earlier commits - they are sure to be pretty ugly.

The API probably feels like the C and C++ libgpiod v2 APIs as I had a hand in those as well (Bart did the work, I did some reviewing and updated the tools), so I probably pushed him in the direction of the Go API I wrote while developing the GPIO uAPI v2 itself (I needed something to drive it from userspace, didn't know Rust then, and updating libgpiod was way too much work - which is one of the reasons libgpiod v2 only just released. So Go did the job at the time.) Though the constraints of writing an extensible and backwardly compatible library interface in those languages adds a whole load of ugliness (maybe not warts, but definitely plenty of pimpls), so my apologies to anyone that has to use them. My Rust API followed the Go, more or less, though as Rust understands ownership the resulting API is clearer, IMHO. On a related note, Linaro thought it was better to write a Rust binding for libgpiod v2 than go Rust native, so libgpiod v2 has a Rust binding included as well (I did some reviewing on that too). That makes little sense to me, as that binding has to deal with the aforementioned C library ugliness, and you gain a dependency on libgpiod itself, when it could just go direct to the ioctls, as gpiocdev does.

Anyway, enough history. Let me know if you find any issues with gpiocdev or need additional features, and I'll see what I can do. Same goes for the uAPI itself.

[ryankurte]

nice work @warthog618! and thank you @fpagliughi for digging into this ^_^

i'm oki with the idea of a swap (and async will be really nice to have!), if we really wanted to we could plug in both backends for the moment and feature gate a swap in case anyone is very attached to the prior version, but, e-h 1.x.y-alpha is still an adventure in breaking changes so it's probably not necessary.

perhaps it's worth a PR here to see how it looks? and if we are adopting this it would be good to add the e-h team to the repo as maintainers with a goal of one day adopting it here if you're open to this @warthog618? (or equally, moving it here and adopting @warthog618 :-P)

[warthog618]

Not something I had considered and, not having much familiarity with rust-embedded team, not something I'm open to at the moment. I'm not ruling it out, but I don't see it as a move that needs to be made urgently, so give it time. Worst case if I get hit by a bus you can fork.