core: provide information about the parent chip in line requests

From: Bartosz Golaszewski <[email protected]>

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

Signed-off-by Bartosz Golaszewski <[email protected]>

---

bindings/rust/libgpiod/src/line_request.rs +0 -0

index 1140aa9..2caab14 100644

Quoted 7 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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

Signed-off-by Bartosz Golaszewski <[email protected]>

---

[...]

Quoted 4 lines

bindings/rust/libgpiod/src/line_request.rs +0 -0

index 1140aa9..2caab14 100644

[...]

bindings/rust/libgpiod/src/line_request.rs impl Request { · line 29

Quoted 5 lines

bindings/rust/libgpiod/src/line_request.rs +1 -0

@@ -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.

bindings/rust/libgpiod/src/line_request.rs impl Request { · line 32

Quoted 3 lines

bindings/rust/libgpiod/src/line_request.rs +3 -0

+        // 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?

(quoted diff) +2 -0

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

bindings/rust/libgpiod/src/line_request.rs impl Request { · line 38

Quoted 7 lines

bindings/rust/libgpiod/src/line_request.rs +5 -0

+        // 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:

[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

Quoted 20 lines · Erik Schilling

Quoted 7 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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

Signed-off-by Bartosz Golaszewski <[email protected]>

---

[...]

Quoted 4 lines

bindings/rust/libgpiod/src/line_request.rs +0 -0

index 1140aa9..2caab14 100644

[...]

Quoted 5 lines

bindings/rust/libgpiod/src/line_request.rs +1 -0

@@ -25,6 +26,17 @@ impl Request {
         Ok(Self { request })
     }
 
+    pub fn chip_path(&self) -> Result<&str> {

Quoted 5 lines

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.

From: Bartosz Golaszewski <[email protected]>

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(-)

Signature · 1 line

2.39.2

Quoted 11 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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.

Quoted 29 lines

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

Quoted 21 lines · Kent Gibson

Quoted 11 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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

Quoted 2 lines

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.

Quoted 25 lines · Bartosz Golaszewski

Quoted 23 lines · Kent Gibson

Quoted 11 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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?

Quoted 4 lines

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?

Quoted 32 lines · Kent Gibson

Quoted 29 lines · Bartosz Golaszewski

Quoted 14 lines · Kent Gibson

Quoted 11 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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.

Quoted 9 lines

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.

Quoted 2 lines

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.

Quoted 33 lines · Bartosz Golaszewski

Quoted 32 lines · Kent Gibson

Quoted 29 lines · Bartosz Golaszewski

Quoted 14 lines · Kent Gibson

Quoted 11 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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.

Quoted 9 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 49 lines · Kent Gibson

Quoted 33 lines · Bartosz Golaszewski

Quoted 32 lines · Kent Gibson

Quoted 29 lines · Bartosz Golaszewski

Quoted 14 lines · Kent Gibson

Quoted 11 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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.

Quoted 9 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 6 lines

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?

Quoted 4 lines

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.

Quoted 50 lines · Bartosz Golaszewski

Quoted 49 lines · Kent Gibson

Quoted 33 lines · Bartosz Golaszewski

Quoted 32 lines · Kent Gibson

Quoted 29 lines · Bartosz Golaszewski

Quoted 14 lines · Kent Gibson

Quoted 11 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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.

Quoted 9 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 9 lines

Quoted 6 lines

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.

Quoted 5 lines

Quoted 4 lines

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?

Quoted 3 lines

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?

Quoted 2 lines

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.

Quoted 10 lines

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

Quoted 3 lines

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?

Quoted 10 lines

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

Quoted 3 lines

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.

Quoted 77 lines · Kent Gibson

Quoted 50 lines · Bartosz Golaszewski

Quoted 49 lines · Kent Gibson

Quoted 33 lines · Bartosz Golaszewski

Quoted 32 lines · Kent Gibson

Quoted 29 lines · Bartosz Golaszewski

Quoted 14 lines · Kent Gibson

Quoted 11 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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.

Quoted 9 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 9 lines

Quoted 6 lines

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.

Quoted 5 lines

Quoted 4 lines

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?

Quoted 6 lines

Quoted 3 lines

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).

Quoted 16 lines

Quoted 2 lines

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.

Quoted 10 lines

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

Quoted 6 lines

Quoted 3 lines

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.

Quoted 14 lines

Quoted 13 lines

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.

Quoted 2 lines

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.

Quoted 3 lines

Where do edge events fit in there?

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

Quoted 132 lines · Bartosz Golaszewski

Quoted 77 lines · Kent Gibson

Quoted 50 lines · Bartosz Golaszewski

Quoted 49 lines · Kent Gibson

Quoted 33 lines · Bartosz Golaszewski

Quoted 32 lines · Kent Gibson

Quoted 29 lines · Bartosz Golaszewski

Quoted 14 lines · Kent Gibson

Quoted 11 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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.

Quoted 9 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 9 lines

Quoted 6 lines

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.

Quoted 5 lines

Quoted 4 lines

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?

Quoted 6 lines

Quoted 3 lines

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).

Quoted 16 lines

Quoted 2 lines

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.

Quoted 10 lines

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

Quoted 6 lines

Quoted 3 lines

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.

Quoted 14 lines

Quoted 13 lines

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.

Quoted 9 lines

Quoted 2 lines

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?

Quoted 5 lines

Quoted 3 lines

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.

Quoted 5 lines · Kent Gibson

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.

Quoted 3 lines

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.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

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.

Quoted 1 line

Quoted 4 lines

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.

Quoted 9 lines · Bartosz Golaszewski

Quoted 5 lines · Kent Gibson

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 19 lines

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

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.

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 7 lines

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?

Quoted 4 lines

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

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

Quoted 11 lines

$ # 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.

Quoted 22 lines · Kent Gibson

Quoted 9 lines · Bartosz Golaszewski

Quoted 5 lines · Kent Gibson

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 6 lines

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.

Quoted 6 lines

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.

Quoted 19 lines

Quoted 19 lines

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

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.

Quoted 5 lines

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.

Quoted 9 lines

Quoted 4 lines

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.

Quoted 8 lines

Quoted 7 lines

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

Quoted 1 line

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?

On Thu, Jul 20, 2023 at 5:27 AM Kent Gibson <[email protected]> wrote:

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