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

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Wed, Mar 4, 2015 at 1:43 PM, Alexandre Courbot <gnurou@xxxxxxxxx> wrote:
> On Tue, Mar 3, 2015 at 7:31 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>> On Tue, Mar 3, 2015 at 9:27 AM, Alexandre Courbot <gnurou@xxxxxxxxx> wrote:
>>
>>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html