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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> wrote: > > > > > > > > > > > > > > > > On Wed, Jul 19, 2023 at 09:20:52PM +0200, Bartosz Golaszewski wrote: > > > > > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > > > > > > > > > > > > > > > > > > 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.