Message-ID: <e642378f-11c2-9def-da75-4a03b5ef8f77@metux.net>
Date:   Fri, 6 Dec 2019 18:50:30 +0100
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Bartosz Golaszewski <brgl@...ev.pl>,
        Kent Gibson <warthog618@...il.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH 0/8] gpiolib: add an ioctl() for monitoring line status
 changes

On 06.12.19 16:44, Linus Walleij wrote:

> The main issue sysfs in its current form had to die was that it relied
> on global GPIO numbers. An alternative to the character device
> would be to use e.g. subdirs for each GPIO chip and export
> local offset numbers from there,

Yes, shouldn't be such a big deal. Maybe I'll find some time to fix
this. Another nice feature would be supporting gpio names for export
and unexport, as well as a file that lists all available gpios.

> but well we reached a fork in the road with the chardev I'd say.

Why can't we support both ? These two interfaces have different use
cases, neither one can replace the other one completely. The cool
thing w/ Linux is the configurability (once I've got some spare time,
I'll create some patches to make the chardev optional :p).

> The main problem solved with the chardev was that scripts that
> died/crashed left the sysfs nodes explicitly exported and
> populated and everything just in the general mess it was at the time
> the application crashed.

Yes, but this cleanup-on-close also could have been done in the old
interface. OTOH, there are use cases where you do not want this,
where sysfs interface is fine (eg. set up certain things in a boot
script, etc)

> Of course it is easy to pose things like that the application should
> register crash handlers or whatnot, but it turns out people weren't
> doing that and with a character device, then it cleans up automatically
> if the application dies or get terminated by a signal for example,

I don't question this usecase. Such automatic cleanup is indeed an
important feature. (even though I never had a practical usecase myself,
where I did go via raw gpios instead of binding some driver).

My bad feelings about chardev comes from entirely different angles, eg:

* not portable, not network transparent (needs special ioctl())
* needs a lot of more code in application side (yes: I also count in
  libraries :p)
* no access control for individual lines
* can't use filesystem (eg. symlinks) to assign application /
  installation specific (path)names, which individual programs can
  act on.

> I see your stance, but it also makes it much easier to shoot
> yourself in the foot.

Yes, you have to care about state tracking (even in error cases) on your
own. Typical issue for such lowlevel things. The optimal case would be
having higher level drivers (eg. led, keys, ...) to bind to, but we're
talking about use cases where that isn't an option.

> Nobody should. The users of userspace GPIO are factory lines,
> industrial control and automation, maker communities and odd
> prototypes. Not deployed products like phones or computers.

Unfortunately, the real-world is different :(

I've had many cases where folks we using raw gpios (with insanely huge
userland code around that) even for trivial things like leds, keys,
serial control lines, etc.

Okay, this isn't a technical, but an educational problem. Don't know
a good solution, except for either trying educate folks or just
ignoring them :o

> The typical cases involves rigging a few relays and sensors
> up in a lab to perform some automation, not dissimilar to e.g.
> PLC (programmable logic controllers) and such. The world is
> full of these one-offs, some in more expensive and intimidating
> environments than others. Some are the lab bench of a few
> select makers. Makers are not important to big capital and
> big business (who are not talking to us) but they are important
> to the community exactly because they are talking to us.

Yeah, expected you'll be saying that ;-)

That bad side here is, this stuff often is going into the field
this way. Seen that many times.

I believe the real problem is on a completely different layer: it's
still too hard (for non-kernel-hackers) to configure things like
platform devices. For DT-based systems we've got DT-overlays (already
solves the kernel side here) - but for non-DT (eg. ACPI) world, it's
ugly. And even worse: if things like gpios come in on probe'able
bus'es like PCI or USB, it gets even more weird.

So, IMHO; the actual topic we should concentrate on is dynamic
multi-level device provisioning / binding. Yes, it's a big topic, but
something I definitively have on my 2do list.


--mtx

---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287

Powered by blists - more mailing lists