Re: Assign line names at runtime

[Kent Gibson <warthog618@xxxxxxxxx>]

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.

If we did want to provide a consistent view of the line namespace, that
might be something the GPIO daemon provides. (conveniently handballing
the problem to Bart ;-)

> Kent Gibson wrote:
> > Alternatively, are named lines the right solution to your problem?
> > Is it important to you that the lines are correctly named, or are you
> > just using the name for the chip/offset lookup?
>
> We would really like to use named lines as they are really convinient, but
> your question actually made me rethink my initial question. We do actually
> not want to change line names, they are constant throughout the runtime of
> a device.
>
> > If the latter perhaps roll your own pinout lookup based on the platform configuration?
>
> The truth might lay in between: We would prefer to use existing features and
> standard interfaces instead of rolling out our own layer. But maybe it's
> just the initial naming that we want to move. A better solution might be to
> add another option to define and probe the GPIO driver at runtime: Instead
> of being required to set all information in the dtb (and therefore from a
> very low level), we might trigger the probing through modprobe and provide
> the GPIO line names from userspace. I'm not sure if such an option exists
> currently?
>

That sounds like the job of the udev rules that Bart suggested - once we have
the ability to rename lines from userspace.

> Best regards and sorry for the quoting style, our mailservers mess with your
> mails.
>

No problem with your quoting style - that looks fine to me - it was the lack
of line wrapping that was the issue. And your response isn't tied into
the email thread either, which is a bit unfortunate.

Oh, and it would be handy to prefix libgpiod specific questions with
[libgpiod], though in this case it has rapidly moved into kernel space
anyway, so no biggy - just for future reference.

Cheers,
Kent.