Re: Fw: [3.18.3] poll() on gpio pins broken

On Wed, Mar 4, 2015 at 1:43 PM, Alexandre Courbot [off-list ref] wrote:

On Tue, Mar 3, 2015 at 7:31 PM, Linus Walleij [off-list ref] wrote:

quoted

On Tue, Mar 3, 2015 at 9:27 AM, Alexandre Courbot [off-list ref] wrote:

quoted

It really comes down to how user-space wants to access GPIOs. I
suspect the majority of sysfs accesses is done by scripts and other
simple programs. If we introduce a char device that takes requires
ioctls, it is then customary to add a small user-space library to
abstract that (for both convenience and safety - think libdrm). Do we
want to maintain libgpio?

Good point.

We have no clue about how the majority out there use the GPIO
sysfs, but I have heard of mission-critical systems just hammering
GPIOs from userspace.

Sadly many of these industrial users are "I just want it to work, now"
types and they don't step forward much on these mailing lists.
(Learned from private conversations...)

Maybe if noone voice their opinion and offer to help with this, we can
assume they don't exist (well obviously a community does not exist)
and their specific needs be ignored until they put their money where
their mouth is.

That's the only way we can handle the situation if people don't
manifest their needs. But does this mean that you would agree with a
cleaner, multi-GPIO friendly sysfs-based solution, or I am
misunderstanding you?

I guess I'm just a bit grumpy.

Whoever comes up with a cleaner sysfs or a clean device interface
will win the argument and lock the path for the other approach.
It's like a forking path with no going back or something.

Yours,
Linus Walleij