Re: [PATCH] pinctrl: intel: Implements gpio free function

["Enrico Weigelt, metux IT consult" <lkml@xxxxxxxxx>]

On 03.04.19 06:13, Linus Walleij wrote:

> But the chardev on the other hand will protect you from all this.> > If the program crashes, the lines will be free:ed.> > If two scripts
try to access the same GPIO, they will be denied.
Right, when you want this concurrency protection and cleanup stiff
the chardev is the better choice. But I've already had several cases
where the simplicity of the sysfs interface is a big win - all you need
few trivial fs operations.

That's also nice for exporting in a grid, eg. via 9P (eg. nice for
quickly building up HIL environments)

ioctls have the bad side effect that they can't be exported via
network in a generic way - your remote fs protocol must support all of
them - even worse: it needs to cope with overlapping ioctl-nr's that
can have entirely different data structures depending on the actual
device. And now try to do that w/ reasonable effort and w/o creating
a shared memory between server and client :p

Another interesting usecase is permission handling:

a) some ioctls need special privileges (oh, how I hate all these "if
   (!capable(CAP_SYS_ADMIN)) ..." lines in the drivers), but you wanna
   give some unprivileged user access to them
b) you wanna give an unprivileged user access to specific gpio's,
   but not to all at once.

With pure filesystem based approach, you can easly define permissions
for each filesystem object.

Yes, these usecases aren't so common for average Jon Doe, but the gpio
subsystem is used that way, out there in the field, and it would be bad
if that functionality would go away someday.


--mtx

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