| Message ID | cover.1638182138.git.viresh.kumar@linaro.org |
|---|---|
| Headers | show |
| Series | libgpiod: Add Rust bindings | expand |
On Mon, Nov 29, 2021 at 11:42 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > Hi Bartosz, > > This patch adds rust bindings for libgpiod v2.0, this is already partially > tested with the virtio rust backend I am developing, which uses these to talk to > the host kernel. > > This is based of the next/post-libgpiod-2.0 branch. > > I haven't added any mock test for this as of now and I am not sure how exactly > am I required to add them. I did see what you mentioned in your patchset about > mock-test vs gpio-sim stuff. Rust also have its own test-framework and I am not > sure if that should be used instead or something else. > > Since I am posting this publicly for the first time, it is still named as V1. I > have not made significant changes to the code since last time, but just divided > the same into multiple files. > > -- > Viresh > > Viresh Kumar (2): > libgpiod: Generate rust FFI bindings > libgpiod: Add rust wrappers > > .gitignore | 6 + > bindings/rust/Cargo.toml | 14 + > bindings/rust/build.rs | 60 ++++ > bindings/rust/src/bindings.rs | 16 ++ > bindings/rust/src/chip.rs | 197 +++++++++++++ > bindings/rust/src/edge_event.rs | 78 +++++ > bindings/rust/src/event_buffer.rs | 59 ++++ > bindings/rust/src/info_event.rs | 70 +++++ > bindings/rust/src/lib.rs | 268 +++++++++++++++++ > bindings/rust/src/line_config.rs | 431 ++++++++++++++++++++++++++++ > bindings/rust/src/line_info.rs | 186 ++++++++++++ > bindings/rust/src/line_request.rs | 218 ++++++++++++++ > bindings/rust/src/request_config.rs | 118 ++++++++ > bindings/rust/wrapper.h | 2 + > 14 files changed, 1723 insertions(+) > create mode 100644 bindings/rust/Cargo.toml > create mode 100644 bindings/rust/build.rs > create mode 100644 bindings/rust/src/bindings.rs > create mode 100644 bindings/rust/src/chip.rs > create mode 100644 bindings/rust/src/edge_event.rs > create mode 100644 bindings/rust/src/event_buffer.rs > create mode 100644 bindings/rust/src/info_event.rs > create mode 100644 bindings/rust/src/lib.rs > create mode 100644 bindings/rust/src/line_config.rs > create mode 100644 bindings/rust/src/line_info.rs > create mode 100644 bindings/rust/src/line_request.rs > create mode 100644 bindings/rust/src/request_config.rs > create mode 100644 bindings/rust/wrapper.h > > -- > 2.31.1.272.g89b43f80a514 > Hi Viresh! Thanks for the hard work on that. Before I even dig into the patches themselves, I'd like to clarify a couple things (because I'm still not sure we're on the same page) and the projected timeline for v2. #1. The v2 API is obviously not stable yet and we're still reworking certain structures (like line_config's accessors). This means I can't merge the bindings just yet but I'm fine with taking them in for v2 given that the missing elements are added, which brings me to: #2. If you look at the existing bindings, you'll notice they all have tests implemented. These tests use the combination of whatever testing framework was chosen for a given language and a wrapper around libgpio-mockup that allows to use the gpio-mockup kernel module to instantiate simulated GPIO devices. I'd like to see a comprehensive test suite for the rust bindings too before they get into the repo. Except that: #3. The development of other parts of the project is currently blocked by the gpio-sim development in the kernel. I don't want to reuse gpio-mockup in v2 because it's simply badly designed. Currently the v11 of the gpio-sim series[1] (based on configfs & sysfs) is on the list and only once it lands in mainline, will we be able to advance the tests for the C, C++ and Python interfaces. This is when the rust tests should be developed too by following what other parts of libgpiod do: providing a wrapper around the future libgpiosim (a wrapper around gpio-sim configfs/sysfs interface that I'll implement once gpio-sim is in next) and then using whatever testing framework for rust is preferable. #4. This one is something you could already add at this time: other bindings contain the examples directory. Inside there are simplified reimplementations of the gpio-tools. It would be very useful for me (as someone not very fluent in rust) to see how those bindings are used in practice. Could you please add it? Thanks! Bart [1] https://lkml.org/lkml/2021/11/30/898
On 01-12-21, 12:08, Bartosz Golaszewski wrote: > Thanks for the hard work on that. Before I even dig into the patches > themselves, I'd like to clarify a couple things (because I'm still not > sure we're on the same page) and the projected timeline for v2. > > #1. The v2 API is obviously not stable yet and we're still reworking > certain structures (like line_config's accessors). This means I can't > merge the bindings just yet but I'm fine with taking them in for v2 > given that the missing elements are added, which brings me to: > > #2. If you look at the existing bindings, you'll notice they all have > tests implemented. These tests use the combination of whatever testing > framework was chosen for a given language and a wrapper around > libgpio-mockup that allows to use the gpio-mockup kernel module to > instantiate simulated GPIO devices. I'd like to see a comprehensive > test suite for the rust bindings too before they get into the repo. > Except that: Yeah, I was able to get around that yesterday, while I was integrating rust's build with Make and understood what we are doing for cpp and python. For now, I dropped the idea of implementing rust tests, and wait for you to go ahead with migrating the python/cpp ones to libgpiosim. > #3. The development of other parts of the project is currently blocked > by the gpio-sim development in the kernel. I don't want to reuse > gpio-mockup in v2 because it's simply badly designed. Currently the > v11 of the gpio-sim series[1] (based on configfs & sysfs) is on the > list I went into details of that as well yesterday, looked nice. > and only once it lands in mainline, will we be able to advance > the tests for the C, C++ and Python interfaces. This is when the rust > tests should be developed too by following what other parts of > libgpiod do: providing a wrapper around the future libgpiosim (a > wrapper around gpio-sim configfs/sysfs interface that I'll implement > once gpio-sim is in next) and then using whatever testing framework > for rust is preferable. Exactly. > #4. This one is something you could already add at this time: other > bindings contain the examples directory. Inside there are simplified > reimplementations of the gpio-tools. It would be very useful for me > (as someone not very fluent in rust) to see how those bindings are > used in practice. Could you please add it? Oh yes, sure. I can do that.