Re: Assign line names at runtime

[Kent Gibson <warthog618@xxxxxxxxx>]

On Fri, Jan 12, 2024 at 12:26:55PM +0100, Bartosz Golaszewski wrote:
> On Fri, Jan 12, 2024 at 1:36 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> >
> > On Thu, Jan 11, 2024 at 04:52:24PM +0000, Westermann, Oliver wrote:
> > > Hey and thanks for your responses, those are actually quite insightful.
> > >
> > > What I read from that is that changing line names really has a lot of
> > > implications.
> > >
> >
> > After sleeping on it, I don't think line renaming is actually such a big issue.
> >
> > Firstly, hot plugging means the line namespace is never going to be
> > static, even if I was tacitly assuming it was.  Turns out I don't think
> > that matters as much as I thought anyway.  We just need to make sure the
> > user is aware of it as well.
> >
> > The analogy I would use is files in a filesystem, where the chip
> > corresponds to a directory and the line a file.  We aren't terribly
> > concerned that a file may be renamed while we do a find, or while
> > opening or using a file, so it should be the same for a line.
> >
> > We rename a file through the directory, so it makes sense to rename the
> > line through the chip, and not require the line to be requested.
> > So we would add a new ioctl on the chip to perform the rename.
> > Could make that more general in case we ever add something else to line
> > info that isn't controlled by requesting the line, but I'm note sure the
> > additional complexity would be worth it, given how unlikely that is.
> > But I digress...
> >
> > We don't inform a user with an open file that it may have been renamed
> > while open, so neither would we with the line. If it is an issue for you
> > then you can add a watch on the line info, similar to using inotify
> > on the filesystem.
> >
> > The point the analogy breaks down a bit is that we allow duplicate names,
> > (I don't think anyone really wants that feature, but historically it has
> > been allowed so we're stuck with it.) but I don't think that is of any
> > consequence to this discussion.
> >
>
> This analogy is great and all but there's one issue with it - we're
> not dealing with a filesystem that everyone can modify. We have more
> or less agreed so far that we allow multiple readers of GPIO
> information but whenever there's any setting done, one needs to
> request the line for exclusive usage. Now we'd break that logic by
> allowing all users to arbitrarily rename GPIO lines and I don't like
> this.
>

Firstly, sorry if I gave the impression I'm all in on this idea - this
is still spitballing.

You are extending the analogy too far, I'm only applying it to names and how
name instability might be viewed from the user's perspective.
I was thinking it could be a deal-breaker, but if it is ok for the
filesystem then maybe not.

I have no problem considering the line name to be metadata, not data (line
configuration and value).

You aren't allowing all users - you are allowing those that have
permission to open the chip, so it can be locked down if necessary, the same
as requesting the line.

Having said all that, I am uneasy that this capability could be abused,
particularly in ways we can't anticipate.
So I'm at the point that I think we could do it, one way or another, but
much less certain if we should.
I would not consider it if there was an alternative.

Cheers,
Kent.