rust-embedded / rust-sysfs-gpio

A Rust Interface to the Linux sysfs GPIO interface (https://www.kernel.org/doc/Documentation/gpio/sysfs.txt)
Apache License 2.0
383 stars 45 forks source link

Upstream deprecation #76

Open orowith2os opened 1 year ago

orowith2os commented 1 year ago

The upstream sysfs interface is deprecated:

THIS ABI IS DEPRECATED, THE ABI DOCUMENTATION HAS BEEN MOVED TO Documentation/ABI/obsolete/sysfs-gpio AND NEW USERSPACE CONSUMERS ARE SUPPOSED TO USE THE CHARACTER DEVICE ABI. THIS OLD SYSFS ABI WILL NOT BE DEVELOPED (NO NEW FEATURES), IT WILL JUST BE MAINTAINED.

As the bare IOCTLs may not be suitable to interact with these devices, it may be better to use libgpiod:

libgpiod - C library and tools for interacting with the linux GPIO character device (gpiod stands for GPIO device) Since linux 4.8 the GPIO sysfs interface is deprecated. User space should use the character device instead. This library encapsulates the ioctl calls and data structures behind a straightforward API.

Several bindings are available, including ones for Rust:

High-level, object-oriented bindings for C++, python3 and Rust are provided.... .... Rust bindings require cargo support. When building the Rust bindings along the C library using make, they will be automatically configured to build against the build results of the C library.

There's also gpiod:

Rust crate for interfacing with Linux GPIO character devices. It provides an interface to the Linux GPIO using the chardev module. This interface involves calling ioctl funcions which are unsafe and require some unintuitive variable mapping. To ease this process, this crate provides a [Chip] struct which encapsulates the interface in safe Rust functions. The functionality provided here is highly inspired by libgpiod.

And gpiocdev:

A Rust library for accessing GPIO lines on Linux platforms using the GPIO character device. This is the equivalent of libgpiod, but in pure Rust.

gpio-cdev warns against using this crate, but this crate makes no note of anything here, and implies that this API is still supported. This is not the case, and it should be updated to account for this.

I don't have much information on this aside from what I've noted here so far, so I probably can't help much for anything.