[libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

While working on the DBus API, it occurred to me that while we can obtain
the list of requested offsets from a line request, this information lacks
context if we cannot get any information about the parent chip on which
the request was made.

We cannot reference the chip in any way as its lifetime is disconnected
from the request but we can at least provide the path to the character
device used to open it as a way of providing some context for the offsets.

This series adds a new getter for struct gpiod_line_request and wrappers
for it for all bindings. This will be used in the upcoming DBus GPIO
manager code.

Bartosz Golaszewski (5):
  core: provide gpiod_line_request_get_chip_path()
  tests: add a test-case for gpiod_line_request_get_chip_path()
  bindings: cxx: provide line_request::chip_path()
  bindings: python: provide the chip_path property in line_request
  bindings: rust: provide LineRequest::chip_path()

 bindings/cxx/gpiodcxx/line-request.hpp       |  7 +++++++
 bindings/cxx/line-request.cpp                | 10 +++++++++-
 bindings/cxx/tests/tests-line-request.cpp    |  6 ++++--
 bindings/python/gpiod/chip.py                |  1 +
 bindings/python/gpiod/line_request.py        | 12 +++++++++--
 bindings/python/tests/tests_line_request.py  | 13 +++++++-----
 bindings/rust/libgpiod/src/line_request.rs   | 12 +++++++++++
 bindings/rust/libgpiod/tests/line_request.rs | 13 ++++++++++++
 include/gpiod.h                              |  9 +++++++++
 lib/chip.c                                   |  2 +-
 lib/internal.h                               |  3 ++-
 lib/line-request.c                           | 20 ++++++++++++++++++-
 tests/tests-line-request.c                   | 21 ++++++++++++++++++++
 13 files changed, 116 insertions(+), 13 deletions(-)

-- 
2.39.2

[libgpiod][PATCH 1/5] core: provide gpiod_line_request_get_chip_path()

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

While we can get the list of requested offsets from a line-request object,
this information lacks context if we don't provide any data about the GPIO
chip the request was made on. Add a helper allowing users to get the path
to the character device used to create the parent chip.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 include/gpiod.h    |  9 +++++++++
 lib/chip.c         |  2 +-
 lib/internal.h     |  3 ++-
 lib/line-request.c | 20 +++++++++++++++++++-
 4 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/include/gpiod.h b/include/gpiod.h
index 3c13783..61f8ef1 100644
--- a/include/gpiod.h
+++ b/include/gpiod.h
@@ -1007,6 +1007,15 @@ gpiod_request_config_get_event_buffer_size(struct gpiod_request_config *config);
  */
 void gpiod_line_request_release(struct gpiod_line_request *request);
 
+/**
+ * @brief Get the path to the chip this request was made on.
+ * @param request Line request object.
+ * @return Path to the GPIO chip device. The returned pointer is valid for the
+ * lifetime of the request object and must not be freed by the caller.
+ */
+const char *
+gpiod_line_request_get_chip_path(struct gpiod_line_request *request);
+
 /**
  * @brief Get the number of lines in the request.
  * @param request Line request object.
diff --git a/lib/chip.c b/lib/chip.c
index 7d4d21e..e94d750 100644
--- a/lib/chip.c
+++ b/lib/chip.c
@@ -237,7 +237,7 @@ gpiod_chip_request_lines(struct gpiod_chip *chip,
 	if (ret < 0)
 		return NULL;
 
-	request = gpiod_line_request_from_uapi(&uapi_req);
+	request = gpiod_line_request_from_uapi(&uapi_req, chip->path);
 	if (!request) {
 		close(uapi_req.fd);
 		return NULL;
diff --git a/lib/internal.h b/lib/internal.h
index ef9b17e..e9ada42 100644
--- a/lib/internal.h
+++ b/lib/internal.h
@@ -26,7 +26,8 @@ void gpiod_request_config_to_uapi(struct gpiod_request_config *config,
 int gpiod_line_config_to_uapi(struct gpiod_line_config *config,
 			      struct gpio_v2_line_request *uapi_cfg);
 struct gpiod_line_request *
-gpiod_line_request_from_uapi(struct gpio_v2_line_request *uapi_req);
+gpiod_line_request_from_uapi(struct gpio_v2_line_request *uapi_req,
+			     const char *chip_path);
 int gpiod_edge_event_buffer_read_fd(int fd,
 				    struct gpiod_edge_event_buffer *buffer,
 				    size_t max_events);
diff --git a/lib/line-request.c b/lib/line-request.c
index e536355..99cbe2c 100644
--- a/lib/line-request.c
+++ b/lib/line-request.c
@@ -13,13 +13,15 @@
 #include "internal.h"
 
 struct gpiod_line_request {
+	char *chip_path;
 	unsigned int offsets[GPIO_V2_LINES_MAX];
 	size_t num_lines;
 	int fd;
 };
 
 struct gpiod_line_request *
-gpiod_line_request_from_uapi(struct gpio_v2_line_request *uapi_req)
+gpiod_line_request_from_uapi(struct gpio_v2_line_request *uapi_req,
+			     const char *chip_path)
 {
 	struct gpiod_line_request *request;
 
@@ -28,6 +30,13 @@ gpiod_line_request_from_uapi(struct gpio_v2_line_request *uapi_req)
 		return NULL;
 
 	memset(request, 0, sizeof(*request));
+
+	request->chip_path = strdup(chip_path);
+	if (!request->chip_path) {
+		free(request);
+		return NULL;
+	}
+
 	request->fd = uapi_req->fd;
 	request->num_lines = uapi_req->num_lines;
 	memcpy(request->offsets, uapi_req->offsets,
@@ -42,9 +51,18 @@ GPIOD_API void gpiod_line_request_release(struct gpiod_line_request *request)
 		return;
 
 	close(request->fd);
+	free(request->chip_path);
 	free(request);
 }
 
+GPIOD_API const char *
+gpiod_line_request_get_chip_path(struct gpiod_line_request *request)
+{
+	assert(request);
+
+	return request->chip_path;
+}
+
 GPIOD_API size_t
 gpiod_line_request_get_num_requested_lines(struct gpiod_line_request *request)
 {
-- 
2.39.2

[libgpiod][PATCH 2/5] tests: add a test-case for gpiod_line_request_get_chip_path()

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Add a test case for the chip path getter on line-request objects.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 tests/tests-line-request.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/tests/tests-line-request.c b/tests/tests-line-request.c
index 0b985e2..2c8c497 100644
--- a/tests/tests-line-request.c
+++ b/tests/tests-line-request.c
@@ -675,3 +675,24 @@ GPIOD_TEST_CASE(get_requested_offsets_less_and_more)
 	g_assert_cmpuint(retrieved[2], ==, 2);
 	g_assert_cmpuint(retrieved[3], ==, 3);
 }
+
+GPIOD_TEST_CASE(get_chip_path)
+{
+	static const guint offset = 4;
+
+	g_autoptr(GPIOSimChip) sim = g_gpiosim_chip_new("num-lines", 8, NULL);
+	g_autoptr(struct_gpiod_chip) chip = NULL;
+	g_autoptr(struct_gpiod_line_config) line_cfg = NULL;
+	g_autoptr(struct_gpiod_line_request) request = NULL;
+
+	chip = gpiod_test_open_chip_or_fail(g_gpiosim_chip_get_dev_path(sim));
+	line_cfg = gpiod_test_create_line_config_or_fail();
+
+	gpiod_test_line_config_add_line_settings_or_fail(line_cfg, &offset, 1,
+							 NULL);
+
+	request = gpiod_test_chip_request_lines_or_fail(chip, NULL, line_cfg);
+
+	g_assert_cmpstr(gpiod_chip_get_path(chip), ==,
+			gpiod_line_request_get_chip_path(request));
+}
-- 
2.39.2

[libgpiod][PATCH 3/5] bindings: cxx: provide line_request::chip_path()

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Provide a wrapper around gpiod_line_request_get_chip_path() for C++
bindings and update the tests.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 bindings/cxx/gpiodcxx/line-request.hpp    |  7 +++++++
 bindings/cxx/line-request.cpp             | 10 +++++++++-
 bindings/cxx/tests/tests-line-request.cpp |  6 ++++--
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/bindings/cxx/gpiodcxx/line-request.hpp b/bindings/cxx/gpiodcxx/line-request.hpp
index c1e1520..dd8b5b9 100644
--- a/bindings/cxx/gpiodcxx/line-request.hpp
+++ b/bindings/cxx/gpiodcxx/line-request.hpp
@@ -14,6 +14,7 @@
 
 #include <chrono>
 #include <cstddef>
+#include <filesystem>
 #include <iostream>
 #include <memory>
 
@@ -75,6 +76,12 @@ public:
 	 */
 	void release();
 
+	/**
+	 * @brief Get the path of the chip this request was made on.
+	 * @return Path to the GPIO chip device.
+	 */
+	::std::filesystem::path chip_path() const;
+
 	/**
 	 * @brief Get the number of requested lines.
 	 * @return Number of lines in this request.
diff --git a/bindings/cxx/line-request.cpp b/bindings/cxx/line-request.cpp
index b0723c3..33e9d6e 100644
--- a/bindings/cxx/line-request.cpp
+++ b/bindings/cxx/line-request.cpp
@@ -63,6 +63,13 @@ GPIOD_CXX_API void line_request::release()
 	this->_m_priv->request.reset();
 }
 
+GPIOD_CXX_API ::std::filesystem::path line_request::chip_path() const
+{
+	this->_m_priv->throw_if_released();
+
+	return ::gpiod_line_request_get_chip_path(this->_m_priv->request.get());
+}
+
 GPIOD_CXX_API ::std::size_t line_request::num_lines() const
 {
 	this->_m_priv->throw_if_released();
@@ -222,7 +229,8 @@ GPIOD_CXX_API ::std::ostream& operator<<(::std::ostream& out, const line_request
 	if (!request)
 		out << "gpiod::line_request(released)";
 	else
-		out << "gpiod::line_request(num_lines=" << request.num_lines() <<
+		out << "gpiod::line_request(chip_path=\"" << request.chip_path() <<
+		       "\", num_lines=" << request.num_lines() <<
 		       ", line_offsets=" << request.offsets() <<
 		       ", fd=" << request.fd() <<
 		       ")";
diff --git a/bindings/cxx/tests/tests-line-request.cpp b/bindings/cxx/tests/tests-line-request.cpp
index d1a56ae..914a60a 100644
--- a/bindings/cxx/tests/tests-line-request.cpp
+++ b/bindings/cxx/tests/tests-line-request.cpp
@@ -468,14 +468,16 @@ TEST_CASE("line_request stream insertion operator works", "[line-request]")
 		.set_num_lines(4)
 		.build();
 
-	auto request = ::gpiod::chip(sim.dev_path())
+	auto chip = ::gpiod::chip(sim.dev_path());
+	auto request = chip
 		.prepare_request()
 		.add_line_settings({ 3, 1, 0, 2}, ::gpiod::line_settings())
 		.do_request();
 
 	::std::stringstream buf, expected;
 
-	expected << "gpiod::line_request(num_lines=4, line_offsets=gpiod::offsets(3, 1, 0, 2), fd=" <<
+	expected << "gpiod::line_request(chip_path=\"" << chip.path() <<
+		    "\", num_lines=4, line_offsets=gpiod::offsets(3, 1, 0, 2), fd=" <<
 		    request.fd() << ")";
 
 	SECTION("active request")
-- 
2.39.2

[libgpiod][PATCH 4/5] bindings: python: provide the chip_path property in line_request

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Provide a wrapper around gpiod_line_request_get_chip_path() for Python
bindings and update the tests.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 bindings/python/gpiod/chip.py               |  1 +
 bindings/python/gpiod/line_request.py       | 12 ++++++++++--
 bindings/python/tests/tests_line_request.py | 13 ++++++++-----
 3 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/bindings/python/gpiod/chip.py b/bindings/python/gpiod/chip.py
index da93370..0629db0 100644
--- a/bindings/python/gpiod/chip.py
+++ b/bindings/python/gpiod/chip.py
@@ -315,6 +315,7 @@ class Chip:
         req_internal = self._chip.request_lines(line_cfg, consumer, event_buffer_size)
         request = LineRequest(req_internal)
 
+        request._chip_path = self.path
         request._offsets = req_internal.offsets
         request._name_map = name_map
         request._offset_map = offset_map
diff --git a/bindings/python/gpiod/line_request.py b/bindings/python/gpiod/line_request.py
index 096bf18..aaae37c 100644
--- a/bindings/python/gpiod/line_request.py
+++ b/bindings/python/gpiod/line_request.py
@@ -212,10 +212,18 @@ class LineRequest:
         if not self._req:
             return "<LineRequest RELEASED>"
 
-        return "<LineRequest num_lines={} offsets={} fd={}>".format(
-            self.num_lines, self.offsets, self.fd
+        return '<LineRequest chip_path="{}" num_lines={} offsets={} fd={}>'.format(
+            self.chip_path, self.num_lines, self.offsets, self.fd
         )
 
+    @property
+    def chip_path(self) -> str:
+        """
+        Path of the chip this request was made on.
+        """
+        self._check_released()
+        return self._chip_path
+
     @property
     def num_lines(self) -> int:
         """
diff --git a/bindings/python/tests/tests_line_request.py b/bindings/python/tests/tests_line_request.py
index aa84b9a..4ab3ea5 100644
--- a/bindings/python/tests/tests_line_request.py
+++ b/bindings/python/tests/tests_line_request.py
@@ -529,11 +529,14 @@ class LineRequestStringRepresentation(TestCase):
         del self.sim
 
     def test_str(self):
-        with gpiod.request_lines(self.sim.dev_path, config={(2, 6, 4, 1): None}) as req:
-            self.assertEqual(
-                str(req),
-                "<LineRequest num_lines=4 offsets=[2, 6, 4, 1] fd={}>".format(req.fd),
-            )
+        with gpiod.Chip(self.sim.dev_path) as chip:
+            with chip.request_lines(config={(2, 6, 4, 1): None}) as req:
+                self.assertEqual(
+                    str(req),
+                    '<LineRequest chip_path="{}" num_lines=4 offsets=[2, 6, 4, 1] fd={}>'.format(
+                        chip.path, req.fd
+                    ),
+                )
 
     def test_str_released(self):
         req = gpiod.request_lines(self.sim.dev_path, config={(2, 6, 4, 1): None})
-- 
2.39.2

[libgpiod][PATCH 5/5] bindings: rust: provide LineRequest::chip_path()

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Provide a wrapper around gpiod_line_request_get_chip_path() for Rust
bindings and add a test-case.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 bindings/rust/libgpiod/src/line_request.rs   | 12 ++++++++++++
 bindings/rust/libgpiod/tests/line_request.rs | 13 +++++++++++++
 2 files changed, 25 insertions(+)

diff --git a/bindings/rust/libgpiod/src/line_request.rs b/bindings/rust/libgpiod/src/line_request.rs
index 1140aa9..2caab14 100644
--- a/bindings/rust/libgpiod/src/line_request.rs
+++ b/bindings/rust/libgpiod/src/line_request.rs
@@ -2,6 +2,7 @@
 // SPDX-FileCopyrightText: 2022 Linaro Ltd.
 // SPDX-FileCopyrightText: 2022 Viresh Kumar <viresh.kumar@linaro.org>
 
+use std::ffi::CStr;
 use std::os::unix::prelude::AsRawFd;
 use std::time::Duration;
 
@@ -25,6 +26,17 @@ impl Request {
         Ok(Self { request })
     }
 
+    pub fn chip_path(&self) -> Result<&str> {
+        // SAFETY: The string returned by libgpiod is guaranteed to live as long
+        // as the `struct LineRequest`.
+        let path = unsafe { gpiod::gpiod_line_request_get_chip_path(self.request) };
+
+        // SAFETY: The string is guaranteed to be valid here by the C API.
+        unsafe { CStr::from_ptr(path) }
+            .to_str()
+            .map_err(Error::StringNotUtf8)
+    }
+
     /// Get the number of lines in the request.
     pub fn num_lines(&self) -> usize {
         // SAFETY: `gpiod_line_request` is guaranteed to be valid here.
diff --git a/bindings/rust/libgpiod/tests/line_request.rs b/bindings/rust/libgpiod/tests/line_request.rs
index d49874f..e4ed9c2 100644
--- a/bindings/rust/libgpiod/tests/line_request.rs
+++ b/bindings/rust/libgpiod/tests/line_request.rs
@@ -59,6 +59,19 @@ mod line_request {
     mod verify {
         use super::*;
 
+        #[test]
+        fn chip_path() {
+            const GPIO: Offset = 2;
+            let mut config = TestConfig::new(NGPIO).unwrap();
+            config.lconfig_add_settings(&[GPIO]);
+            config.request_lines().unwrap();
+
+            let dev_path = config.sim().lock().unwrap().dev_path();
+            let s = dev_path.into_os_string().into_string().unwrap();
+
+            assert_eq!(config.request().chip_path().unwrap(), s);
+        }
+
         #[test]
         fn custom_consumer() {
             const GPIO: Offset = 2;
-- 
2.39.2

Re: [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[Kent Gibson]

On Wed, Jul 19, 2023 at 09:20:52PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> While working on the DBus API, it occurred to me that while we can obtain
> the list of requested offsets from a line request, this information lacks
> context if we cannot get any information about the parent chip on which
> the request was made.
> 
> We cannot reference the chip in any way as its lifetime is disconnected
> from the request but we can at least provide the path to the character
> device used to open it as a way of providing some context for the offsets.
> 

No problem with this conceptually, the only question I have is which
one of these should be stored:
 - requested path e.g. 'a_symlink_to_my_favorite_chip'
 - canonicalised path e.g. '/dev/gpiochip0'
 - chip name e.g. 'gpiochip0'
 - chip number e.g. 0

In this patch we get the requested path, right?

Cheers,
Kent.

> This series adds a new getter for struct gpiod_line_request and wrappers
> for it for all bindings. This will be used in the upcoming DBus GPIO
> manager code.
> 
> Bartosz Golaszewski (5):
>   core: provide gpiod_line_request_get_chip_path()
>   tests: add a test-case for gpiod_line_request_get_chip_path()
>   bindings: cxx: provide line_request::chip_path()
>   bindings: python: provide the chip_path property in line_request
>   bindings: rust: provide LineRequest::chip_path()
> 
>  bindings/cxx/gpiodcxx/line-request.hpp       |  7 +++++++
>  bindings/cxx/line-request.cpp                | 10 +++++++++-
>  bindings/cxx/tests/tests-line-request.cpp    |  6 ++++--
>  bindings/python/gpiod/chip.py                |  1 +
>  bindings/python/gpiod/line_request.py        | 12 +++++++++--
>  bindings/python/tests/tests_line_request.py  | 13 +++++++-----
>  bindings/rust/libgpiod/src/line_request.rs   | 12 +++++++++++
>  bindings/rust/libgpiod/tests/line_request.rs | 13 ++++++++++++
>  include/gpiod.h                              |  9 +++++++++
>  lib/chip.c                                   |  2 +-
>  lib/internal.h                               |  3 ++-
>  lib/line-request.c                           | 20 ++++++++++++++++++-
>  tests/tests-line-request.c                   | 21 ++++++++++++++++++++
>  13 files changed, 116 insertions(+), 13 deletions(-)
> 
> -- 
> 2.39.2
> 

Re: [libgpiod][PATCH 5/5] bindings: rust: provide LineRequest::chip_path()

[Erik Schilling]

On Wed Jul 19, 2023 at 9:20 PM CEST, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> Provide a wrapper around gpiod_line_request_get_chip_path() for Rust
> bindings and add a test-case.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
[...]
> diff --git a/bindings/rust/libgpiod/src/line_request.rs b/bindings/rust/libgpiod/src/line_request.rs
> index 1140aa9..2caab14 100644
> --- a/bindings/rust/libgpiod/src/line_request.rs
> +++ b/bindings/rust/libgpiod/src/line_request.rs
[...]
> @@ -25,6 +26,17 @@ impl Request {
>          Ok(Self { request })
>      }
>  
> +    pub fn chip_path(&self) -> Result<&str> {

A rustdoc comment `/// <explanation>` on the function may be helpful.
The other functions have some (though those could probably also be a
little longer...).

More importantly, _if_ this function is returning a file path, then I
would consider to return a Path [1]. The conversion from &str -> Path is
"0-cost" and makes the API more explicit. `Sim::dev_path()` also returns
a PathBuf so the conversion in the test would become a little easier.

> +        // SAFETY: The string returned by libgpiod is guaranteed to live as long
> +        // as the `struct LineRequest`.
> +        let path = unsafe { gpiod::gpiod_line_request_get_chip_path(self.request) };

The SAFETY comment should explain why the following `unsafe` block is
safe. For this block, the lifetime of the string does not matter for
safety. Instead, it should explain why self.request is valid and safe
to use.

Maybe like this?

+        // SAFETY: The `gpiod_line_request` is guaranteed to be live as long
+        // as `&self`


> +        // SAFETY: The string is guaranteed to be valid here by the C API.
> +        unsafe { CStr::from_ptr(path) }
> +            .to_str()
> +            .map_err(Error::StringNotUtf8)
> +    }

Here the lifetime of the string is important then! Checking the
Cstr::from_ptr doc [2], one needs to ensure that:

- The memory pointed to by ptr must contain a valid nul terminator at
  the end of the string.
- ptr must be valid for reads of bytes up to and including the null
  terminator.
- The memory referenced by the returned CStr must not be mutated for the
  duration of lifetime 'a.

The SAFETY comment should explain why these three requirements are
satisfied.

Suggestion:

+        // SAFETY: The string is guaranteed to be valid, non-null and immutable
+        // by the C API for the lifetime of the `gpiod_line_request`. The
+        // `gpiod_line_request` is living as long as `&self`. The string is
+        // returned read-only with a lifetime of `&self`.

[1] https://doc.rust-lang.org/stable/std/path/struct.Path.html
[2] https://doc.rust-lang.org/std/ffi/struct.CStr.html#method.from_ptr

[...]

LGTM otherwise.

- Erik

Re: [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[Bartosz Golaszewski]

On Thu, Jul 20, 2023 at 5:27 AM Kent Gibson <warthog618@gmail.com> wrote:
>
> On Wed, Jul 19, 2023 at 09:20:52PM +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > While working on the DBus API, it occurred to me that while we can obtain
> > the list of requested offsets from a line request, this information lacks
> > context if we cannot get any information about the parent chip on which
> > the request was made.
> >
> > We cannot reference the chip in any way as its lifetime is disconnected
> > from the request but we can at least provide the path to the character
> > device used to open it as a way of providing some context for the offsets.
> >
>
> No problem with this conceptually, the only question I have is which
> one of these should be stored:
>  - requested path e.g. 'a_symlink_to_my_favorite_chip'
>  - canonicalised path e.g. '/dev/gpiochip0'
>  - chip name e.g. 'gpiochip0'
>  - chip number e.g. 0
>
> In this patch we get the requested path, right?
>

Yes, I think we should just use whatever filesystem path was used to
create the chip as it would be the one allowing the caller to reopen
the same chip.

Bart

> Cheers,
> Kent.
>
> > This series adds a new getter for struct gpiod_line_request and wrappers
> > for it for all bindings. This will be used in the upcoming DBus GPIO
> > manager code.
> >
> > Bartosz Golaszewski (5):
> >   core: provide gpiod_line_request_get_chip_path()
> >   tests: add a test-case for gpiod_line_request_get_chip_path()
> >   bindings: cxx: provide line_request::chip_path()
> >   bindings: python: provide the chip_path property in line_request
> >   bindings: rust: provide LineRequest::chip_path()
> >
> >  bindings/cxx/gpiodcxx/line-request.hpp       |  7 +++++++
> >  bindings/cxx/line-request.cpp                | 10 +++++++++-
> >  bindings/cxx/tests/tests-line-request.cpp    |  6 ++++--
> >  bindings/python/gpiod/chip.py                |  1 +
> >  bindings/python/gpiod/line_request.py        | 12 +++++++++--
> >  bindings/python/tests/tests_line_request.py  | 13 +++++++-----
> >  bindings/rust/libgpiod/src/line_request.rs   | 12 +++++++++++
> >  bindings/rust/libgpiod/tests/line_request.rs | 13 ++++++++++++
> >  include/gpiod.h                              |  9 +++++++++
> >  lib/chip.c                                   |  2 +-
> >  lib/internal.h                               |  3 ++-
> >  lib/line-request.c                           | 20 ++++++++++++++++++-
> >  tests/tests-line-request.c                   | 21 ++++++++++++++++++++
> >  13 files changed, 116 insertions(+), 13 deletions(-)
> >
> > --
> > 2.39.2
> >

Re: [libgpiod][PATCH 5/5] bindings: rust: provide LineRequest::chip_path()

[Bartosz Golaszewski]

On Thu, Jul 20, 2023 at 7:04 AM Erik Schilling
<erik.schilling@linaro.org> wrote:
>
> On Wed Jul 19, 2023 at 9:20 PM CEST, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > Provide a wrapper around gpiod_line_request_get_chip_path() for Rust
> > bindings and add a test-case.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > ---
> [...]
> > diff --git a/bindings/rust/libgpiod/src/line_request.rs b/bindings/rust/libgpiod/src/line_request.rs
> > index 1140aa9..2caab14 100644
> > --- a/bindings/rust/libgpiod/src/line_request.rs
> > +++ b/bindings/rust/libgpiod/src/line_request.rs
> [...]
> > @@ -25,6 +26,17 @@ impl Request {
> >          Ok(Self { request })
> >      }
> >
> > +    pub fn chip_path(&self) -> Result<&str> {
>
> A rustdoc comment `/// <explanation>` on the function may be helpful.
> The other functions have some (though those could probably also be a
> little longer...).
>
> More importantly, _if_ this function is returning a file path, then I
> would consider to return a Path [1]. The conversion from &str -> Path is
> "0-cost" and makes the API more explicit. `Sim::dev_path()` also returns
> a PathBuf so the conversion in the test would become a little easier.
>

I wanted to stay in line with chip's path() getter which also returns
Result<&str>. As you're saying - the user can convert it at 0 cost if
needed.

Bart

> > +        // SAFETY: The string returned by libgpiod is guaranteed to live as long
> > +        // as the `struct LineRequest`.
> > +        let path = unsafe { gpiod::gpiod_line_request_get_chip_path(self.request) };
>
> The SAFETY comment should explain why the following `unsafe` block is
> safe. For this block, the lifetime of the string does not matter for
> safety. Instead, it should explain why self.request is valid and safe
> to use.
>
> Maybe like this?
>
> +        // SAFETY: The `gpiod_line_request` is guaranteed to be live as long
> +        // as `&self`
>
>
> > +        // SAFETY: The string is guaranteed to be valid here by the C API.
> > +        unsafe { CStr::from_ptr(path) }
> > +            .to_str()
> > +            .map_err(Error::StringNotUtf8)
> > +    }
>
> Here the lifetime of the string is important then! Checking the
> Cstr::from_ptr doc [2], one needs to ensure that:
>
> - The memory pointed to by ptr must contain a valid nul terminator at
>   the end of the string.
> - ptr must be valid for reads of bytes up to and including the null
>   terminator.
> - The memory referenced by the returned CStr must not be mutated for the
>   duration of lifetime 'a.
>
> The SAFETY comment should explain why these three requirements are
> satisfied.
>
> Suggestion:
>
> +        // SAFETY: The string is guaranteed to be valid, non-null and immutable
> +        // by the C API for the lifetime of the `gpiod_line_request`. The
> +        // `gpiod_line_request` is living as long as `&self`. The string is
> +        // returned read-only with a lifetime of `&self`.
>

I'll take the suggestions verbatim, thanks!

Bart

> [1] https://doc.rust-lang.org/stable/std/path/struct.Path.html
> [2] https://doc.rust-lang.org/std/ffi/struct.CStr.html#method.from_ptr
>
> [...]
>
> LGTM otherwise.
>
> - Erik

Re: [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[Kent Gibson]

On Thu, Jul 20, 2023 at 09:59:00AM +0200, Bartosz Golaszewski wrote:
> On Thu, Jul 20, 2023 at 5:27 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Wed, Jul 19, 2023 at 09:20:52PM +0200, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > >
> > > While working on the DBus API, it occurred to me that while we can obtain
> > > the list of requested offsets from a line request, this information lacks
> > > context if we cannot get any information about the parent chip on which
> > > the request was made.
> > >
> > > We cannot reference the chip in any way as its lifetime is disconnected
> > > from the request but we can at least provide the path to the character
> > > device used to open it as a way of providing some context for the offsets.
> > >
> >
> > No problem with this conceptually, the only question I have is which
> > one of these should be stored:
> >  - requested path e.g. 'a_symlink_to_my_favorite_chip'
> >  - canonicalised path e.g. '/dev/gpiochip0'
> >  - chip name e.g. 'gpiochip0'
> >  - chip number e.g. 0
> >
> > In this patch we get the requested path, right?
> >
> 
> Yes, I think we should just use whatever filesystem path was used to
> create the chip as it would be the one allowing the caller to reopen
> the same chip.
> 

So there are instances where those four don't map to the same thing?

Cheers,
Kent.

Re: [libgpiod][PATCH 5/5] bindings: rust: provide LineRequest::chip_path()

[Erik Schilling]

On Thu Jul 20, 2023 at 10:04 AM CEST, Bartosz Golaszewski wrote:
> On Thu, Jul 20, 2023 at 7:04 AM Erik Schilling
> <erik.schilling@linaro.org> wrote:
> >
> > On Wed Jul 19, 2023 at 9:20 PM CEST, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > >
> > > Provide a wrapper around gpiod_line_request_get_chip_path() for Rust
> > > bindings and add a test-case.
> > >
> > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > > ---
> > [...]
> > > diff --git a/bindings/rust/libgpiod/src/line_request.rs b/bindings/rust/libgpiod/src/line_request.rs
> > > index 1140aa9..2caab14 100644
> > > --- a/bindings/rust/libgpiod/src/line_request.rs
> > > +++ b/bindings/rust/libgpiod/src/line_request.rs
> > [...]
> > > @@ -25,6 +26,17 @@ impl Request {
> > >          Ok(Self { request })
> > >      }
> > >
> > > +    pub fn chip_path(&self) -> Result<&str> {
[...]
> > More importantly, _if_ this function is returning a file path, then I
> > would consider to return a Path [1]. The conversion from &str -> Path is
> > "0-cost" and makes the API more explicit. `Sim::dev_path()` also returns
> > a PathBuf so the conversion in the test would become a little easier.
> >
>
> I wanted to stay in line with chip's path() getter which also returns
> Result<&str>. As you're saying - the user can convert it at 0 cost if
> needed.

Makes sense. Did not notice that it is used as &str elsewhere.

- Erik

Re: [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[Bartosz Golaszewski]

On Thu, Jul 20, 2023 at 10:05 AM Kent Gibson <warthog618@gmail.com> wrote:
>
> On Thu, Jul 20, 2023 at 09:59:00AM +0200, Bartosz Golaszewski wrote:
> > On Thu, Jul 20, 2023 at 5:27 AM Kent Gibson <warthog618@gmail.com> wrote:
> > >
> > > On Wed, Jul 19, 2023 at 09:20:52PM +0200, Bartosz Golaszewski wrote:
> > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > > >
> > > > While working on the DBus API, it occurred to me that while we can obtain
> > > > the list of requested offsets from a line request, this information lacks
> > > > context if we cannot get any information about the parent chip on which
> > > > the request was made.
> > > >
> > > > We cannot reference the chip in any way as its lifetime is disconnected
> > > > from the request but we can at least provide the path to the character
> > > > device used to open it as a way of providing some context for the offsets.
> > > >
> > >
> > > No problem with this conceptually, the only question I have is which
> > > one of these should be stored:
> > >  - requested path e.g. 'a_symlink_to_my_favorite_chip'
> > >  - canonicalised path e.g. '/dev/gpiochip0'
> > >  - chip name e.g. 'gpiochip0'
> > >  - chip number e.g. 0
> > >
> > > In this patch we get the requested path, right?
> > >
> >
> > Yes, I think we should just use whatever filesystem path was used to
> > create the chip as it would be the one allowing the caller to reopen
> > the same chip.
> >
>
> So there are instances where those four don't map to the same thing?
>

Not in a typical situation, it can happen if the chip was removed and
another one took its place which is very unlikely.

I just think that we cannot have any "hard data" as in: a programmatic
reference to the chip in the request (their lifetimes are not
connected), so the next best thing is the filesystem path.

Bart

Re: [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[Kent Gibson]

On Thu, Jul 20, 2023 at 10:25:14AM +0200, Bartosz Golaszewski wrote:
> On Thu, Jul 20, 2023 at 10:05 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Thu, Jul 20, 2023 at 09:59:00AM +0200, Bartosz Golaszewski wrote:
> > > On Thu, Jul 20, 2023 at 5:27 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > >
> > > > On Wed, Jul 19, 2023 at 09:20:52PM +0200, Bartosz Golaszewski wrote:
> > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > > > >
> > > > > While working on the DBus API, it occurred to me that while we can obtain
> > > > > the list of requested offsets from a line request, this information lacks
> > > > > context if we cannot get any information about the parent chip on which
> > > > > the request was made.
> > > > >
> > > > > We cannot reference the chip in any way as its lifetime is disconnected
> > > > > from the request but we can at least provide the path to the character
> > > > > device used to open it as a way of providing some context for the offsets.
> > > > >
> > > >
> > > > No problem with this conceptually, the only question I have is which
> > > > one of these should be stored:
> > > >  - requested path e.g. 'a_symlink_to_my_favorite_chip'
> > > >  - canonicalised path e.g. '/dev/gpiochip0'
> > > >  - chip name e.g. 'gpiochip0'
> > > >  - chip number e.g. 0
> > > >
> > > > In this patch we get the requested path, right?
> > > >
> > >
> > > Yes, I think we should just use whatever filesystem path was used to
> > > create the chip as it would be the one allowing the caller to reopen
> > > the same chip.
> > >
> >
> > So there are instances where those four don't map to the same thing?
> >
> 
> Not in a typical situation, it can happen if the chip was removed and
> another one took its place which is very unlikely.
> 

And a symlink could get changed as well.

> I just think that we cannot have any "hard data" as in: a programmatic
> reference to the chip in the request (their lifetimes are not
> connected), so the next best thing is the filesystem path.
> 

Indeed - the chip fd used to request the line is out of scope.

But the number of possible requested paths is many, whereas the other
three options produce a unique and comparable identifier, in a searching
sense.

On a related point, does the DBus API allow a client to access lines
requested by another client?  And if so, how can they be sure they have
the right line?

Cheers,
Kent.

Re: [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[Andy Shevchenko]

On Thu, Jul 20, 2023 at 09:59:00AM +0200, Bartosz Golaszewski wrote:
> On Thu, Jul 20, 2023 at 5:27 AM Kent Gibson <warthog618@gmail.com> wrote:

...

> as it would be the one allowing the caller to reopen the same chip.

Since you do not control the lifetime of the files, the above may not be
guaranteed. So, this path is just an arbitrary information from the past.
It _was_ consistent with the request, but it does _not_ mean it still is.

I would rely on the chip name, which is provided by the DT/driver, if
possible.

-- 
With Best Regards,
Andy Shevchenko

Re: [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[Bartosz Golaszewski]

On Thu, Jul 20, 2023 at 10:39 AM Kent Gibson <warthog618@gmail.com> wrote:
>
> On Thu, Jul 20, 2023 at 10:25:14AM +0200, Bartosz Golaszewski wrote:
> > On Thu, Jul 20, 2023 at 10:05 AM Kent Gibson <warthog618@gmail.com> wrote:
> > >
> > > On Thu, Jul 20, 2023 at 09:59:00AM +0200, Bartosz Golaszewski wrote:
> > > > On Thu, Jul 20, 2023 at 5:27 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > > >
> > > > > On Wed, Jul 19, 2023 at 09:20:52PM +0200, Bartosz Golaszewski wrote:
> > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > > > > >
> > > > > > While working on the DBus API, it occurred to me that while we can obtain
> > > > > > the list of requested offsets from a line request, this information lacks
> > > > > > context if we cannot get any information about the parent chip on which
> > > > > > the request was made.
> > > > > >
> > > > > > We cannot reference the chip in any way as its lifetime is disconnected
> > > > > > from the request but we can at least provide the path to the character
> > > > > > device used to open it as a way of providing some context for the offsets.
> > > > > >
> > > > >
> > > > > No problem with this conceptually, the only question I have is which
> > > > > one of these should be stored:
> > > > >  - requested path e.g. 'a_symlink_to_my_favorite_chip'
> > > > >  - canonicalised path e.g. '/dev/gpiochip0'
> > > > >  - chip name e.g. 'gpiochip0'
> > > > >  - chip number e.g. 0
> > > > >
> > > > > In this patch we get the requested path, right?
> > > > >
> > > >
> > > > Yes, I think we should just use whatever filesystem path was used to
> > > > create the chip as it would be the one allowing the caller to reopen
> > > > the same chip.
> > > >
> > >
> > > So there are instances where those four don't map to the same thing?
> > >
> >
> > Not in a typical situation, it can happen if the chip was removed and
> > another one took its place which is very unlikely.
> >
>
> And a symlink could get changed as well.
>
> > I just think that we cannot have any "hard data" as in: a programmatic
> > reference to the chip in the request (their lifetimes are not
> > connected), so the next best thing is the filesystem path.
> >
>
> Indeed - the chip fd used to request the line is out of scope.
>
> But the number of possible requested paths is many, whereas the other
> three options produce a unique and comparable identifier, in a searching
> sense.
>

So which one do you suggest?

> On a related point, does the DBus API allow a client to access lines
> requested by another client?  And if so, how can they be sure they have
> the right line?
>

Sure they can but various user permissions as configured in the
relevant .conf file may apply.

So what I've got so far in dbus (and feel free to check out the WiP[1]) is this:

There's an /io/gpiod1/gpiochipX object per chip implementing the
io.gpiod1.Chip interface. For each line there's a separate object as
well:

/io/gpiod1/gpiochip0
/io/gpiod1/gpiochip0/0
/io/gpiod1/gpiochip0/1
/io/gpiod1/gpiochip0/2
/io/gpiod1/gpiochip0/3

Line objects implement the io.gpiod1.Line interface and the daemon
emits a PropertiesChanged signal for any status changes.

You can call io.gpiod1.Chip.RequestLines() method on a chip object
which will return the object path to the new request.

/io/gpiod1/gpiochip0
/io/gpiod1/gpiochip0/0
/io/gpiod1/gpiochip0/1
/io/gpiod1/gpiochip0/2
/io/gpiod1/gpiochip0/3
/io/gpiod1/request0

The request will reference the chip object from which it was created
as well as the lines it controls.

Bart

> Cheers,
> Kent.

[1] https://github.com/brgl/libgpiod-private/tree/topic/dbus/

Re: [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[Kent Gibson]

On Thu, Jul 20, 2023 at 10:49:46AM +0200, Bartosz Golaszewski wrote:
> On Thu, Jul 20, 2023 at 10:39 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Thu, Jul 20, 2023 at 10:25:14AM +0200, Bartosz Golaszewski wrote:
> > > On Thu, Jul 20, 2023 at 10:05 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > >
> > > > On Thu, Jul 20, 2023 at 09:59:00AM +0200, Bartosz Golaszewski wrote:
> > > > > On Thu, Jul 20, 2023 at 5:27 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > > > >
> > > > > > On Wed, Jul 19, 2023 at 09:20:52PM +0200, Bartosz Golaszewski wrote:
> > > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > > > > > >
> > > > > > > While working on the DBus API, it occurred to me that while we can obtain
> > > > > > > the list of requested offsets from a line request, this information lacks
> > > > > > > context if we cannot get any information about the parent chip on which
> > > > > > > the request was made.
> > > > > > >
> > > > > > > We cannot reference the chip in any way as its lifetime is disconnected
> > > > > > > from the request but we can at least provide the path to the character
> > > > > > > device used to open it as a way of providing some context for the offsets.
> > > > > > >
> > > > > >
> > > > > > No problem with this conceptually, the only question I have is which
> > > > > > one of these should be stored:
> > > > > >  - requested path e.g. 'a_symlink_to_my_favorite_chip'
> > > > > >  - canonicalised path e.g. '/dev/gpiochip0'
> > > > > >  - chip name e.g. 'gpiochip0'
> > > > > >  - chip number e.g. 0
> > > > > >
> > > > > > In this patch we get the requested path, right?
> > > > > >
> > > > >
> > > > > Yes, I think we should just use whatever filesystem path was used to
> > > > > create the chip as it would be the one allowing the caller to reopen
> > > > > the same chip.
> > > > >
> > > >
> > > > So there are instances where those four don't map to the same thing?
> > > >
> > >
> > > Not in a typical situation, it can happen if the chip was removed and
> > > another one took its place which is very unlikely.
> > >
> >
> > And a symlink could get changed as well.
> >
> > > I just think that we cannot have any "hard data" as in: a programmatic
> > > reference to the chip in the request (their lifetimes are not
> > > connected), so the next best thing is the filesystem path.
> > >
> >
> > Indeed - the chip fd used to request the line is out of scope.
> >
> > But the number of possible requested paths is many, whereas the other
> > three options produce a unique and comparable identifier, in a searching
> > sense.
> >
> 
> So which one do you suggest?
> 

Any of the latter three are equivlent, so you can use whichever is most
convenient.  I've used canonical path in my Rust library, and chip name
in my Go library.  IIRC in Rust I had the canonical path handy and it
was easier to keep it as is than to break it down to name or number.
Why I went with name in the Go is lost in the mists of time.
I do recall toying with going with number but I wasn't sure if gpiochips
were guaranteed to be named 'gpiochipN'.

Given what you have below for DBus, name looks the most natural to me.

> > On a related point, does the DBus API allow a client to access lines
> > requested by another client?  And if so, how can they be sure they have
> > the right line?
> >
> 
> Sure they can but various user permissions as configured in the
> relevant .conf file may apply.
> 

So setting up the dbus-daemon security policy for the objects?

> So what I've got so far in dbus (and feel free to check out the WiP[1]) is this:
> 

I have had a quick look at it, but so far only a quick look and I'm not
familiar with DBus so there is a lot of background to fill in.

> There's an /io/gpiod1/gpiochipX object per chip implementing the
> io.gpiod1.Chip interface. For each line there's a separate object as
> well:
> 
> /io/gpiod1/gpiochip0
> /io/gpiod1/gpiochip0/0
> /io/gpiod1/gpiochip0/1
> /io/gpiod1/gpiochip0/2
> /io/gpiod1/gpiochip0/3
> 
> Line objects implement the io.gpiod1.Line interface and the daemon
> emits a PropertiesChanged signal for any status changes.
> 

Can the client select which of those signals it sees?

> You can call io.gpiod1.Chip.RequestLines() method on a chip object
> which will return the object path to the new request.
> 
> /io/gpiod1/gpiochip0
> /io/gpiod1/gpiochip0/0
> /io/gpiod1/gpiochip0/1
> /io/gpiod1/gpiochip0/2
> /io/gpiod1/gpiochip0/3
> /io/gpiod1/request0
> 
> The request will reference the chip object from which it was created
> as well as the lines it controls.
> 

What about the reverse mapping?


Where do edge events fit in there?

Cheers,
Kent.

Re: [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[Bartosz Golaszewski]

On Thu, Jul 20, 2023 at 11:16 AM Kent Gibson <warthog618@gmail.com> wrote:
>
> On Thu, Jul 20, 2023 at 10:49:46AM +0200, Bartosz Golaszewski wrote:
> > On Thu, Jul 20, 2023 at 10:39 AM Kent Gibson <warthog618@gmail.com> wrote:
> > >
> > > On Thu, Jul 20, 2023 at 10:25:14AM +0200, Bartosz Golaszewski wrote:
> > > > On Thu, Jul 20, 2023 at 10:05 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > > >
> > > > > On Thu, Jul 20, 2023 at 09:59:00AM +0200, Bartosz Golaszewski wrote:
> > > > > > On Thu, Jul 20, 2023 at 5:27 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > > > > >
> > > > > > > On Wed, Jul 19, 2023 at 09:20:52PM +0200, Bartosz Golaszewski wrote:
> > > > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > > > > > > >
> > > > > > > > While working on the DBus API, it occurred to me that while we can obtain
> > > > > > > > the list of requested offsets from a line request, this information lacks
> > > > > > > > context if we cannot get any information about the parent chip on which
> > > > > > > > the request was made.
> > > > > > > >
> > > > > > > > We cannot reference the chip in any way as its lifetime is disconnected
> > > > > > > > from the request but we can at least provide the path to the character
> > > > > > > > device used to open it as a way of providing some context for the offsets.
> > > > > > > >
> > > > > > >
> > > > > > > No problem with this conceptually, the only question I have is which
> > > > > > > one of these should be stored:
> > > > > > >  - requested path e.g. 'a_symlink_to_my_favorite_chip'
> > > > > > >  - canonicalised path e.g. '/dev/gpiochip0'
> > > > > > >  - chip name e.g. 'gpiochip0'
> > > > > > >  - chip number e.g. 0
> > > > > > >
> > > > > > > In this patch we get the requested path, right?
> > > > > > >
> > > > > >
> > > > > > Yes, I think we should just use whatever filesystem path was used to
> > > > > > create the chip as it would be the one allowing the caller to reopen
> > > > > > the same chip.
> > > > > >
> > > > >
> > > > > So there are instances where those four don't map to the same thing?
> > > > >
> > > >
> > > > Not in a typical situation, it can happen if the chip was removed and
> > > > another one took its place which is very unlikely.
> > > >
> > >
> > > And a symlink could get changed as well.
> > >
> > > > I just think that we cannot have any "hard data" as in: a programmatic
> > > > reference to the chip in the request (their lifetimes are not
> > > > connected), so the next best thing is the filesystem path.
> > > >
> > >
> > > Indeed - the chip fd used to request the line is out of scope.
> > >
> > > But the number of possible requested paths is many, whereas the other
> > > three options produce a unique and comparable identifier, in a searching
> > > sense.
> > >
> >
> > So which one do you suggest?
> >
>
> Any of the latter three are equivlent, so you can use whichever is most
> convenient.  I've used canonical path in my Rust library, and chip name
> in my Go library.  IIRC in Rust I had the canonical path handy and it
> was easier to keep it as is than to break it down to name or number.
> Why I went with name in the Go is lost in the mists of time.
> I do recall toying with going with number but I wasn't sure if gpiochips
> were guaranteed to be named 'gpiochipN'.
>
> Given what you have below for DBus, name looks the most natural to me.
>
> > > On a related point, does the DBus API allow a client to access lines
> > > requested by another client?  And if so, how can they be sure they have
> > > the right line?
> > >
> >
> > Sure they can but various user permissions as configured in the
> > relevant .conf file may apply.
> >
>
> So setting up the dbus-daemon security policy for the objects?
>

Not per-object unfortunately, I don't think this is possible with the
standard dbus-daemon or dbus-broker. May be possible in the daemon
itself if we can get the UID of the peer (we can get credentials of
peers in pure DBus but I'm not sure if we can do it when passing
through a bus daemon).

> > So what I've got so far in dbus (and feel free to check out the WiP[1]) is this:
> >
>
> I have had a quick look at it, but so far only a quick look and I'm not
> familiar with DBus so there is a lot of background to fill in.
>
> > There's an /io/gpiod1/gpiochipX object per chip implementing the
> > io.gpiod1.Chip interface. For each line there's a separate object as
> > well:
> >
> > /io/gpiod1/gpiochip0
> > /io/gpiod1/gpiochip0/0
> > /io/gpiod1/gpiochip0/1
> > /io/gpiod1/gpiochip0/2
> > /io/gpiod1/gpiochip0/3
> >
> > Line objects implement the io.gpiod1.Line interface and the daemon
> > emits a PropertiesChanged signal for any status changes.
> >
>
> Can the client select which of those signals it sees?
>

They can listen for PropertiesChanged on a single line but will get an
event on any change and will have to filter out the unwanted
themselves.

> > You can call io.gpiod1.Chip.RequestLines() method on a chip object
> > which will return the object path to the new request.
> >
> > /io/gpiod1/gpiochip0
> > /io/gpiod1/gpiochip0/0
> > /io/gpiod1/gpiochip0/1
> > /io/gpiod1/gpiochip0/2
> > /io/gpiod1/gpiochip0/3
> > /io/gpiod1/request0
> >
> > The request will reference the chip object from which it was created
> > as well as the lines it controls.
> >
>
> What about the reverse mapping?
>

As in: line-to-request? Not sure this is needed? I want the
io.gpiod1.Line interface to expose GetValue/SetValue methods and let
the daemon figure out the mapping logic internally. These methods
would fail if the line is not part of any request controlled by the
daemon.

>
> Where do edge events fit in there?
>

It's a signal exposed by the io.gpiod1.Line interface.

Bart

> Cheers,
> Kent.

Re: [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[Kent Gibson]

On Thu, Jul 20, 2023 at 11:38:19AM +0200, Bartosz Golaszewski wrote:
> On Thu, Jul 20, 2023 at 11:16 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Thu, Jul 20, 2023 at 10:49:46AM +0200, Bartosz Golaszewski wrote:
> > > On Thu, Jul 20, 2023 at 10:39 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > >
> > > > On Thu, Jul 20, 2023 at 10:25:14AM +0200, Bartosz Golaszewski wrote:
> > > > > On Thu, Jul 20, 2023 at 10:05 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > > > >
> > > > > > On Thu, Jul 20, 2023 at 09:59:00AM +0200, Bartosz Golaszewski wrote:
> > > > > > > On Thu, Jul 20, 2023 at 5:27 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Wed, Jul 19, 2023 at 09:20:52PM +0200, Bartosz Golaszewski wrote:
> > > > > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > > > > > > > >
> > > > > > > > > While working on the DBus API, it occurred to me that while we can obtain
> > > > > > > > > the list of requested offsets from a line request, this information lacks
> > > > > > > > > context if we cannot get any information about the parent chip on which
> > > > > > > > > the request was made.
> > > > > > > > >
> > > > > > > > > We cannot reference the chip in any way as its lifetime is disconnected
> > > > > > > > > from the request but we can at least provide the path to the character
> > > > > > > > > device used to open it as a way of providing some context for the offsets.
> > > > > > > > >
> > > > > > > >
> > > > > > > > No problem with this conceptually, the only question I have is which
> > > > > > > > one of these should be stored:
> > > > > > > >  - requested path e.g. 'a_symlink_to_my_favorite_chip'
> > > > > > > >  - canonicalised path e.g. '/dev/gpiochip0'
> > > > > > > >  - chip name e.g. 'gpiochip0'
> > > > > > > >  - chip number e.g. 0
> > > > > > > >
> > > > > > > > In this patch we get the requested path, right?
> > > > > > > >
> > > > > > >
> > > > > > > Yes, I think we should just use whatever filesystem path was used to
> > > > > > > create the chip as it would be the one allowing the caller to reopen
> > > > > > > the same chip.
> > > > > > >
> > > > > >
> > > > > > So there are instances where those four don't map to the same thing?
> > > > > >
> > > > >
> > > > > Not in a typical situation, it can happen if the chip was removed and
> > > > > another one took its place which is very unlikely.
> > > > >
> > > >
> > > > And a symlink could get changed as well.
> > > >
> > > > > I just think that we cannot have any "hard data" as in: a programmatic
> > > > > reference to the chip in the request (their lifetimes are not
> > > > > connected), so the next best thing is the filesystem path.
> > > > >
> > > >
> > > > Indeed - the chip fd used to request the line is out of scope.
> > > >
> > > > But the number of possible requested paths is many, whereas the other
> > > > three options produce a unique and comparable identifier, in a searching
> > > > sense.
> > > >
> > >
> > > So which one do you suggest?
> > >
> >
> > Any of the latter three are equivlent, so you can use whichever is most
> > convenient.  I've used canonical path in my Rust library, and chip name
> > in my Go library.  IIRC in Rust I had the canonical path handy and it
> > was easier to keep it as is than to break it down to name or number.
> > Why I went with name in the Go is lost in the mists of time.
> > I do recall toying with going with number but I wasn't sure if gpiochips
> > were guaranteed to be named 'gpiochipN'.
> >
> > Given what you have below for DBus, name looks the most natural to me.
> >
> > > > On a related point, does the DBus API allow a client to access lines
> > > > requested by another client?  And if so, how can they be sure they have
> > > > the right line?
> > > >
> > >
> > > Sure they can but various user permissions as configured in the
> > > relevant .conf file may apply.
> > >
> >
> > So setting up the dbus-daemon security policy for the objects?
> >
> 
> Not per-object unfortunately, I don't think this is possible with the
> standard dbus-daemon or dbus-broker. May be possible in the daemon
> itself if we can get the UID of the peer (we can get credentials of
> peers in pure DBus but I'm not sure if we can do it when passing
> through a bus daemon).
> 
> > > So what I've got so far in dbus (and feel free to check out the WiP[1]) is this:
> > >
> >
> > I have had a quick look at it, but so far only a quick look and I'm not
> > familiar with DBus so there is a lot of background to fill in.
> >
> > > There's an /io/gpiod1/gpiochipX object per chip implementing the
> > > io.gpiod1.Chip interface. For each line there's a separate object as
> > > well:
> > >
> > > /io/gpiod1/gpiochip0
> > > /io/gpiod1/gpiochip0/0
> > > /io/gpiod1/gpiochip0/1
> > > /io/gpiod1/gpiochip0/2
> > > /io/gpiod1/gpiochip0/3
> > >
> > > Line objects implement the io.gpiod1.Line interface and the daemon
> > > emits a PropertiesChanged signal for any status changes.
> > >
> >
> > Can the client select which of those signals it sees?
> >
> 
> They can listen for PropertiesChanged on a single line but will get an
> event on any change and will have to filter out the unwanted
> themselves.
> 
> > > You can call io.gpiod1.Chip.RequestLines() method on a chip object
> > > which will return the object path to the new request.
> > >
> > > /io/gpiod1/gpiochip0
> > > /io/gpiod1/gpiochip0/0
> > > /io/gpiod1/gpiochip0/1
> > > /io/gpiod1/gpiochip0/2
> > > /io/gpiod1/gpiochip0/3
> > > /io/gpiod1/request0
> > >
> > > The request will reference the chip object from which it was created
> > > as well as the lines it controls.
> > >
> >
> > What about the reverse mapping?
> >
> 
> As in: line-to-request? Not sure this is needed? I want the
> io.gpiod1.Line interface to expose GetValue/SetValue methods and let
> the daemon figure out the mapping logic internally. These methods
> would fail if the line is not part of any request controlled by the
> daemon.
> 

The case I was thinking of was wanting to release a line, and if you
don't know which request you will have to walk the request objects.

And what of lines that are requested directly by apps other than the
gpio-manager?

> >
> > Where do edge events fit in there?
> >
> 
> It's a signal exposed by the io.gpiod1.Line interface.

But separate from the PropertiesChanged?


I am also wondering if the tools can be extended with the option to
perform their ops using the gpio-manager, particularly get/set/mon that
currently require exclusive access.

Cheers,
Kent.

Re: [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[Bartosz Golaszewski]

On Thu, Jul 20, 2023 at 11:52 AM Kent Gibson <warthog618@gmail.com> wrote:
>
> On Thu, Jul 20, 2023 at 11:38:19AM +0200, Bartosz Golaszewski wrote:
> > On Thu, Jul 20, 2023 at 11:16 AM Kent Gibson <warthog618@gmail.com> wrote:
> > >
> > > On Thu, Jul 20, 2023 at 10:49:46AM +0200, Bartosz Golaszewski wrote:
> > > > On Thu, Jul 20, 2023 at 10:39 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > > >
> > > > > On Thu, Jul 20, 2023 at 10:25:14AM +0200, Bartosz Golaszewski wrote:
> > > > > > On Thu, Jul 20, 2023 at 10:05 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > > > > >
> > > > > > > On Thu, Jul 20, 2023 at 09:59:00AM +0200, Bartosz Golaszewski wrote:
> > > > > > > > On Thu, Jul 20, 2023 at 5:27 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Jul 19, 2023 at 09:20:52PM +0200, Bartosz Golaszewski wrote:
> > > > > > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > > > > > > > > >
> > > > > > > > > > While working on the DBus API, it occurred to me that while we can obtain
> > > > > > > > > > the list of requested offsets from a line request, this information lacks
> > > > > > > > > > context if we cannot get any information about the parent chip on which
> > > > > > > > > > the request was made.
> > > > > > > > > >
> > > > > > > > > > We cannot reference the chip in any way as its lifetime is disconnected
> > > > > > > > > > from the request but we can at least provide the path to the character
> > > > > > > > > > device used to open it as a way of providing some context for the offsets.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > No problem with this conceptually, the only question I have is which
> > > > > > > > > one of these should be stored:
> > > > > > > > >  - requested path e.g. 'a_symlink_to_my_favorite_chip'
> > > > > > > > >  - canonicalised path e.g. '/dev/gpiochip0'
> > > > > > > > >  - chip name e.g. 'gpiochip0'
> > > > > > > > >  - chip number e.g. 0
> > > > > > > > >
> > > > > > > > > In this patch we get the requested path, right?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Yes, I think we should just use whatever filesystem path was used to
> > > > > > > > create the chip as it would be the one allowing the caller to reopen
> > > > > > > > the same chip.
> > > > > > > >
> > > > > > >
> > > > > > > So there are instances where those four don't map to the same thing?
> > > > > > >
> > > > > >
> > > > > > Not in a typical situation, it can happen if the chip was removed and
> > > > > > another one took its place which is very unlikely.
> > > > > >
> > > > >
> > > > > And a symlink could get changed as well.
> > > > >
> > > > > > I just think that we cannot have any "hard data" as in: a programmatic
> > > > > > reference to the chip in the request (their lifetimes are not
> > > > > > connected), so the next best thing is the filesystem path.
> > > > > >
> > > > >
> > > > > Indeed - the chip fd used to request the line is out of scope.
> > > > >
> > > > > But the number of possible requested paths is many, whereas the other
> > > > > three options produce a unique and comparable identifier, in a searching
> > > > > sense.
> > > > >
> > > >
> > > > So which one do you suggest?
> > > >
> > >
> > > Any of the latter three are equivlent, so you can use whichever is most
> > > convenient.  I've used canonical path in my Rust library, and chip name
> > > in my Go library.  IIRC in Rust I had the canonical path handy and it
> > > was easier to keep it as is than to break it down to name or number.
> > > Why I went with name in the Go is lost in the mists of time.
> > > I do recall toying with going with number but I wasn't sure if gpiochips
> > > were guaranteed to be named 'gpiochipN'.
> > >
> > > Given what you have below for DBus, name looks the most natural to me.
> > >
> > > > > On a related point, does the DBus API allow a client to access lines
> > > > > requested by another client?  And if so, how can they be sure they have
> > > > > the right line?
> > > > >
> > > >
> > > > Sure they can but various user permissions as configured in the
> > > > relevant .conf file may apply.
> > > >
> > >
> > > So setting up the dbus-daemon security policy for the objects?
> > >
> >
> > Not per-object unfortunately, I don't think this is possible with the
> > standard dbus-daemon or dbus-broker. May be possible in the daemon
> > itself if we can get the UID of the peer (we can get credentials of
> > peers in pure DBus but I'm not sure if we can do it when passing
> > through a bus daemon).
> >
> > > > So what I've got so far in dbus (and feel free to check out the WiP[1]) is this:
> > > >
> > >
> > > I have had a quick look at it, but so far only a quick look and I'm not
> > > familiar with DBus so there is a lot of background to fill in.
> > >
> > > > There's an /io/gpiod1/gpiochipX object per chip implementing the
> > > > io.gpiod1.Chip interface. For each line there's a separate object as
> > > > well:
> > > >
> > > > /io/gpiod1/gpiochip0
> > > > /io/gpiod1/gpiochip0/0
> > > > /io/gpiod1/gpiochip0/1
> > > > /io/gpiod1/gpiochip0/2
> > > > /io/gpiod1/gpiochip0/3
> > > >
> > > > Line objects implement the io.gpiod1.Line interface and the daemon
> > > > emits a PropertiesChanged signal for any status changes.
> > > >
> > >
> > > Can the client select which of those signals it sees?
> > >
> >
> > They can listen for PropertiesChanged on a single line but will get an
> > event on any change and will have to filter out the unwanted
> > themselves.
> >
> > > > You can call io.gpiod1.Chip.RequestLines() method on a chip object
> > > > which will return the object path to the new request.
> > > >
> > > > /io/gpiod1/gpiochip0
> > > > /io/gpiod1/gpiochip0/0
> > > > /io/gpiod1/gpiochip0/1
> > > > /io/gpiod1/gpiochip0/2
> > > > /io/gpiod1/gpiochip0/3
> > > > /io/gpiod1/request0
> > > >
> > > > The request will reference the chip object from which it was created
> > > > as well as the lines it controls.
> > > >
> > >
> > > What about the reverse mapping?
> > >
> >
> > As in: line-to-request? Not sure this is needed? I want the
> > io.gpiod1.Line interface to expose GetValue/SetValue methods and let
> > the daemon figure out the mapping logic internally. These methods
> > would fail if the line is not part of any request controlled by the
> > daemon.
> >
>
> The case I was thinking of was wanting to release a line, and if you
> don't know which request you will have to walk the request objects.
>

You cannot release a single line if it's part of a wider request though.

> And what of lines that are requested directly by apps other than the
> gpio-manager?
>

You can tell they're used but cannot request them just like with any
other user of the cdev.

> > >
> > > Where do edge events fit in there?
> > >
> >
> > It's a signal exposed by the io.gpiod1.Line interface.
>
> But separate from the PropertiesChanged?
>

Yes. PropertiesChanged is emitted on changes in properties (direction,
edge, all reported by gpionotify) while EdgeEvent is for edges
exclusively.

>
> I am also wondering if the tools can be extended with the option to
> perform their ops using the gpio-manager, particularly get/set/mon that
> currently require exclusive access.
>

There's a client app already functional in my WiP branch. Think nmcli
for NetworkManager. It doesn't link against libgpiod - only uses the
DBus API.

You can do something like this (not all of this is implemented yet):

$ # Wait for a chip with a particular label to appear
$ gpiocli wait --chip="foobar" --timeout=10s
$ # Request a line for edge events
$ gpiocli request --input --rising-edge --falling-edge foo
request0
$ # List available requests
$ gpiocli requests
request0 (gpiochip0) offsets: [4]
$ # Wait for edge events:
$ gpiocli monitor foo
Offset: 4 RISING EDGE Timestamp: 3425234234
$ # Release the request
$ gpiocli release request0

This way the user can easily use bash scripts, command line or even
any DBus library out there while we still use the character device in
the daemon and ditch sysfs.

Bart

> Cheers,
> Kent.
>

Re: [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[Kent Gibson]

On Thu, Jul 20, 2023 at 02:30:45PM +0200, Bartosz Golaszewski wrote:
> On Thu, Jul 20, 2023 at 11:52 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> >
> > The case I was thinking of was wanting to release a line, and if you
> > don't know which request you will have to walk the request objects.
> >
> 
> You cannot release a single line if it's part of a wider request though.
> 

Of course. Unless we were to extend the uAPI to allow that.

> > And what of lines that are requested directly by apps other than the
> > gpio-manager?
> >
> 
> You can tell they're used but cannot request them just like with any
> other user of the cdev.
> 

This is going to be a pain point - the concept of "used" is getting
muddy.

Say two processes want to get a line.
So both need to request it before they can get it?
Or only one does the request and both can get?

The latter case is painful to use.
The former requires request being idempotent or at least to return an
error that distiguishes a line already held by gpio-manager and a line
already held but not by gpio-manager.

> > > >
> > > > Where do edge events fit in there?
> > > >
> > >
> > > It's a signal exposed by the io.gpiod1.Line interface.
> >
> > But separate from the PropertiesChanged?
> >
> 
> Yes. PropertiesChanged is emitted on changes in properties (direction,
> edge, all reported by gpionotify) while EdgeEvent is for edges
> exclusively.
> 
> >
> > I am also wondering if the tools can be extended with the option to
> > perform their ops using the gpio-manager, particularly get/set/mon that
> > currently require exclusive access.
> >
> 
> There's a client app already functional in my WiP branch. Think nmcli
> for NetworkManager. It doesn't link against libgpiod - only uses the
> DBus API.
> 

Sure - doesn't mean other tools can't use the DBus API too.
My thinking was existing users of GPIO tools could just add
an option, say -D, to their scripts to switch over to gpio-manager.

> You can do something like this (not all of this is implemented yet):
> 
> $ # Wait for a chip with a particular label to appear
> $ gpiocli wait --chip="foobar" --timeout=10s
> $ # Request a line for edge events
> $ gpiocli request --input --rising-edge --falling-edge foo
> request0

Will that support multiple lines, possibly spanning multiple chips?

> $ # List available requests
> $ gpiocli requests
> request0 (gpiochip0) offsets: [4]

But that will only return the requests made by gpio-manager, right?

> $ # Wait for edge events:
> $ gpiocli monitor foo
> Offset: 4 RISING EDGE Timestamp: 3425234234
> $ # Release the request
> $ gpiocli release request0
> 
> This way the user can easily use bash scripts, command line or even
> any DBus library out there while we still use the character device in
> the daemon and ditch sysfs.
> 

Agreed.  As covered earlier, access control needs to be fleshed out, but
other than that I don't see any obvious deal breakers.

Cheers,
Kent.

Re: [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[Bartosz Golaszewski]

On Thu, Jul 20, 2023 at 3:37 PM Kent Gibson <warthog618@gmail.com> wrote:
>
> On Thu, Jul 20, 2023 at 02:30:45PM +0200, Bartosz Golaszewski wrote:
> > On Thu, Jul 20, 2023 at 11:52 AM Kent Gibson <warthog618@gmail.com> wrote:
> > >
> > >
> > > The case I was thinking of was wanting to release a line, and if you
> > > don't know which request you will have to walk the request objects.
> > >
> >
> > You cannot release a single line if it's part of a wider request though.
> >
>
> Of course. Unless we were to extend the uAPI to allow that.
>
> > > And what of lines that are requested directly by apps other than the
> > > gpio-manager?
> > >
> >
> > You can tell they're used but cannot request them just like with any
> > other user of the cdev.
> >
>
> This is going to be a pain point - the concept of "used" is getting
> muddy.
>
> Say two processes want to get a line.
> So both need to request it before they can get it?
> Or only one does the request and both can get?

I think I badly worded the previous answer. The GPIO manager has no
notion of a user. It just receives a message from the bus. It's the
daemon that filters the users (e.g. only users in "gpio" group can
request and set/get GPIOs). So the answer is: one user can in fact
request a line, it stays requested by the manager and then another
user can set it or even release it as long as it's got the permissions
to do so. This is similar to how sysfs works.

>
> The latter case is painful to use.
> The former requires request being idempotent or at least to return an
> error that distiguishes a line already held by gpio-manager and a line
> already held but not by gpio-manager.
>

This should be fine. The manager knows if it's the one controlling a
line. It's just a matter of distinct error codes.

> > > > >
> > > > > Where do edge events fit in there?
> > > > >
> > > >
> > > > It's a signal exposed by the io.gpiod1.Line interface.
> > >
> > > But separate from the PropertiesChanged?
> > >
> >
> > Yes. PropertiesChanged is emitted on changes in properties (direction,
> > edge, all reported by gpionotify) while EdgeEvent is for edges
> > exclusively.
> >
> > >
> > > I am also wondering if the tools can be extended with the option to
> > > perform their ops using the gpio-manager, particularly get/set/mon that
> > > currently require exclusive access.
> > >
> >
> > There's a client app already functional in my WiP branch. Think nmcli
> > for NetworkManager. It doesn't link against libgpiod - only uses the
> > DBus API.
> >
>
> Sure - doesn't mean other tools can't use the DBus API too.
> My thinking was existing users of GPIO tools could just add
> an option, say -D, to their scripts to switch over to gpio-manager.
>

The functionality of the DBus API doesn't have a full overlap with
using the library. I don't see why we would want to do this. It would
introduce a lot of overhead for no reason. I think a separate client
that doesn't use any libgpiod APIs at all is what's needed.

> > You can do something like this (not all of this is implemented yet):
> >
> > $ # Wait for a chip with a particular label to appear
> > $ gpiocli wait --chip="foobar" --timeout=10s
> > $ # Request a line for edge events
> > $ gpiocli request --input --rising-edge --falling-edge foo
> > request0
>
> Will that support multiple lines, possibly spanning multiple chips?

Multiple lines, sure. Spanning multiple chips: I don't think so. Why
would we need this?

>
> > $ # List available requests
> > $ gpiocli requests
> > request0 (gpiochip0) offsets: [4]
>
> But that will only return the requests made by gpio-manager, right?

Yes.

Bart

>
> > $ # Wait for edge events:
> > $ gpiocli monitor foo
> > Offset: 4 RISING EDGE Timestamp: 3425234234
> > $ # Release the request
> > $ gpiocli release request0
> >
> > This way the user can easily use bash scripts, command line or even
> > any DBus library out there while we still use the character device in
> > the daemon and ditch sysfs.
> >
>
> Agreed.  As covered earlier, access control needs to be fleshed out, but
> other than that I don't see any obvious deal breakers.
>
> Cheers,
> Kent.

Re: [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[Kent Gibson]

On Thu, Jul 20, 2023 at 05:01:09PM +0200, Bartosz Golaszewski wrote:
> On Thu, Jul 20, 2023 at 3:37 PM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Thu, Jul 20, 2023 at 02:30:45PM +0200, Bartosz Golaszewski wrote:
> > > On Thu, Jul 20, 2023 at 11:52 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > >
> > > >
> > > > The case I was thinking of was wanting to release a line, and if you
> > > > don't know which request you will have to walk the request objects.
> > > >
> > >
> > > You cannot release a single line if it's part of a wider request though.
> > >
> >
> > Of course. Unless we were to extend the uAPI to allow that.
> >
> > > > And what of lines that are requested directly by apps other than the
> > > > gpio-manager?
> > > >
> > >
> > > You can tell they're used but cannot request them just like with any
> > > other user of the cdev.
> > >
> >
> > This is going to be a pain point - the concept of "used" is getting
> > muddy.
> >
> > Say two processes want to get a line.
> > So both need to request it before they can get it?
> > Or only one does the request and both can get?
> 
> I think I badly worded the previous answer. The GPIO manager has no
> notion of a user. It just receives a message from the bus. It's the
> daemon that filters the users (e.g. only users in "gpio" group can
> request and set/get GPIOs). So the answer is: one user can in fact
> request a line, it stays requested by the manager and then another
> user can set it or even release it as long as it's got the permissions
> to do so. This is similar to how sysfs works.
> 

Sure.  The point I was trying to make is how does the user determine if
they can release the line via gpio-manager?  Currently they have to walk
the requests looking for the line - and they might not find it.

This is only a minor pain point - in practice the processes will most
likely all be using gpio-manager.

> >
> > The latter case is painful to use.
> > The former requires request being idempotent or at least to return an
> > error that distiguishes a line already held by gpio-manager and a line
> > already held but not by gpio-manager.
> >
> 
> This should be fine. The manager knows if it's the one controlling a
> line. It's just a matter of distinct error codes.
> 
> > > > > >
> > > > > > Where do edge events fit in there?
> > > > > >
> > > > >
> > > > > It's a signal exposed by the io.gpiod1.Line interface.
> > > >
> > > > But separate from the PropertiesChanged?
> > > >
> > >
> > > Yes. PropertiesChanged is emitted on changes in properties (direction,
> > > edge, all reported by gpionotify) while EdgeEvent is for edges
> > > exclusively.
> > >
> > > >
> > > > I am also wondering if the tools can be extended with the option to
> > > > perform their ops using the gpio-manager, particularly get/set/mon that
> > > > currently require exclusive access.
> > > >
> > >
> > > There's a client app already functional in my WiP branch. Think nmcli
> > > for NetworkManager. It doesn't link against libgpiod - only uses the
> > > DBus API.
> > >
> >
> > Sure - doesn't mean other tools can't use the DBus API too.
> > My thinking was existing users of GPIO tools could just add
> > an option, say -D, to their scripts to switch over to gpio-manager.
> >
> 
> The functionality of the DBus API doesn't have a full overlap with
> using the library. I don't see why we would want to do this. It would
> introduce a lot of overhead for no reason. I think a separate client
> that doesn't use any libgpiod APIs at all is what's needed.
> 

Fair enough. That works for me.

> > > You can do something like this (not all of this is implemented yet):
> > >
> > > $ # Wait for a chip with a particular label to appear
> > > $ gpiocli wait --chip="foobar" --timeout=10s
> > > $ # Request a line for edge events
> > > $ gpiocli request --input --rising-edge --falling-edge foo
> > > request0
> >
> > Will that support multiple lines, possibly spanning multiple chips?
> 
> Multiple lines, sure. Spanning multiple chips: I don't think so. Why
> would we need this?
> 

There is no need - the user can make multiple requests as they are now
persistant.  Just wondering what the API looks like to the user.

Cheers,
Kent.