Re: [RFC] GPIO User I/O

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

Hi Rodolfo!

thanks for your mail.

On Mon, Jul 6, 2020 at 2:19 PM Rodolfo Giometti <giometti@xxxxxxxxxxxx> wrote:

> 4) Then users will find a new class with entries, one for each new line:
>
> # ls /sys/class/gpio-uio/
> bypass-1  bypass0
>
> 5) By using the attribute "line" the users can get or set the line status
>
> # cat /sys/class/gpio-uio/bypass-1/line
> 0
> # echo 1 > /sys/class/gpio-uio/bypass-1/line
> # cat /sys/class/gpio-uio/bypass-1/line
> 1

This interface is problematic because it extends the sysfs ABI which is
obsolete. This is why the documentation of this ABI has been moved to
Documentation/ABI/obsolete/sysfs-gpio  for many years.

The sysfs approach has several problems which are summarized like
this in the commit where it was introduced:

commit 3c702e9987e261042a07e43460a8148be254412e
Author: Linus Walleij <linus.walleij@xxxxxxxxxx>
Date:   Wed Oct 21 15:29:53 2015 +0200

    gpio: add a userspace chardev ABI for GPIOs

    A new chardev that is to be used for userspace GPIO access is
    added in this patch. It is intended to gradually replace the
    horribly broken sysfs ABI.

    Using a chardev has many upsides:

    - All operations are per-gpiochip, which is the actual
      device underlying the GPIOs, making us tie in to the
      kernel device model properly.

    - Hotpluggable GPIO controllers can come and go, as this
      kind of problem has been know to userspace for character
      devices since ages, and if a gpiochip handle is held in
      userspace we know we will break something, whereas the
      sysfs is stateless.

    - The one-value-per-file rule of sysfs is really hard to
      maintain when you want to twist more than one knob at a time,
      for example have in-kernel APIs to switch several GPIO
      lines at the same time, and this will be possible to do
      with a single ioctl() from userspace, saving a lot of
      context switching.
(...)

Another thing that is not mentioned here is that when a character
device is opened it is automatically closed if a process crashes,
which means that kernelspace can do clean-ups and reference counting
and making the lines available to other consumers (like if you
restart the program).

With Geert's GPIO aggregator userspace and device tree can conjure
special per-usecase gpio chips as pointed out by Drew: this is
very useful when you want some kernel-managed yet
usecase-specific GPIO lines in a special "container" chip.
To me this is the best of two worlds. (Kernelspace and userspace.)

Yours,
Linus Walleij