Update dependency on sysfs_gpio and fix clippy warnings

[jannic]

No description provided.

[jannic]

There are still several dependencies that could be updated or replaced.

[eldruin]

Thank you so much!
Do you know of any users that would need the MSRV to be kept at 1.75?
Otherwise, given that this crate is so stale (we even have to port the CI to GHA), I would be fine with raising it even higher if that eases the breakage potential here, since pinning transitive dependencies is already necessary with this PR.

[sirhcel]

Do you know of any users that would need the MSRV to be kept at 1.75? Otherwise, given that this crate is so stale (we even have to port the CI to GHA), I would be fine with raising it even higher if that eases the breakage potential here, since pinning transitive dependencies is already necessary with this PR.

The latest Yocto Long-Term-Support release Scarthgap ships with Rust 1.75.0. This is the environment where at least I'm dealing with sysfs GPIOs.

And yes, having a CI set up for this crate would be great. I already thought about it and now I'm on the verge letting myself getting nerdnsniped into actually doing it.

[sirhcel]

Alright. I checked this on a Raspberry Pi 3 with Debian 11 Bullseye (as sysfs GPIO support is no longer available/active with Debian 12 Bookworm). There are still some rough edges which don't look like being related to the changes made here:

• Default symlink dir /var/run/gpio not being available on a Raspberry Pi OS by default (Error No such file or directory #17)
• Errors from presumed export delays where the first shot exports the pin but shows an error and the second shot in a row goes smoothly (Error No such file or directory #17)
• Dead links for contribution and (code of conduct) (Contributing.md Link is Dead #13)
• Errors from unexported pins breaking/stopping status output

I tried to remodel CLI parsing when transitioning from Clap 2 to Clap 4 without causing breakage. However, I did not manage to invoke the tool in its current state 02b0658 due to constantly getting errors from CLI parsing and having no clue how to actually invoke gpio. For example:

$ ./target/debug/gpio --config examples/raspberrypi.toml export-all --symlink-root /tmp/gpio
error: Found argument '--symlink-root' which wasn't expected, or isn't valid in this context
        Did you mean to put '--symlink-root' after the subcommand 'export'?

USAGE:
    gpio --config <config>... <SUBCOMMAND>

For more information try --help

I also added some quick and dirty CI builds and link checks. Link checks fail due to the current state. But I would include them nevertheless to increase the pressure on getting them fixed.

But with the rough edges but aside, things are ready to merge from my side.

[sirhcel]

Created #33 to tackle the actually broken links.

[sirhcel]

Transitioning from the error-chain crate to thiserror gives me exactly the same error message output in this example:

• error-chain

  $ cargo run --quiet -- --config examples/raspberrypi.toml --config examples/raspberrypi-sirhcel.toml status
  | Number     | Exported   | Direction  | Active Low | Names      | Value      |
  +------------+------------+------------+------------+------------+------------+
  | 2          | true       | Out        | false      | GPIO02     | 0          |
  |            |            |            |            | PIN03      |            |
  |            |            |            |            | SDA1       |            |
  +------------+------------+------------+------------+------------+------------+
  | 3          | true       | In         | false      | GPIO03     | 1          |
  |            |            |            |            | PIN05      |            |
  |            |            |            |            | SCL1       |            |
  +------------+------------+------------+------------+------------+------------+
  ERROR: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })
  

• thiserror

  cargo run --quiet -- --config examples/raspberrypi.toml --config examples/raspberrypi-sirhcel.toml status
  | Number     | Exported   | Direction  | Active Low | Names      | Value      |
  +------------+------------+------------+------------+------------+------------+
  | 2          | true       | Out        | false      | GPIO02     | 0          |
  |            |            |            |            | PIN03      |            |
  |            |            |            |            | SDA1       |            |
  +------------+------------+------------+------------+------------+------------+
  | 3          | true       | In         | false      | GPIO03     | 1          |
  |            |            |            |            | PIN05      |            |
  |            |            |            |            | SCL1       |            |
  +------------+------------+------------+------------+------------+------------+
  ERROR: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })
  

[jannic]

However, I did not manage to invoke the tool in its current state 02b0658 due to constantly getting errors from CLI parsing and having no clue how to actually invoke gpio.

As mentioned on Matrix, this is because the old version required --config=examples/raspberrypi.toml instead of --config examples/raspberrypi.toml. This is surprising as the help output states the opposite:

OPTIONS:
    -c, --config <config>...    additional configuration to use

With this PR, both variants work.

There are some rough edges as you mentioned, and I agree they are not caused by the update. For everything I tried, the old and the new version reported the same errors. So I didn't find any regression, and if you are holding it right, the tool does what it should.

Tested on a Raspberry Pi 3, with Raspberry Pi OS based on bookworm, but kernel downgraded to 6.1.0 to get the old sysfs gpio interface back.

That said, I don't have much experience with this tool, so all I actually did was exporting and unexporting the GPIO pins, manually toggling one of them, and verifying that the voltage on the pin actually changes.

[eldruin]

Great work! Thank you so much @jannic! and also @sirhcel for testing!