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

[Michael Welling <mwelling@ieee.org>]

On Mon, Mar 09, 2015 at 04:52:26PM +0100, Linus Walleij wrote:
> On Wed, Mar 4, 2015 at 1:43 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
> > On Tue, Mar 3, 2015 at 7:31 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> >> On Tue, Mar 3, 2015 at 9:27 AM, Alexandre Courbot <gnurou@gmail.com> 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.

There is no need to fork and in fact it would probably be a bad idea.

At EMAC we support both sysfs and character device simultaneously.
Sysfs for the ease of use and ioctl for real time advantages.

Not saying that it is a good reference but the two interfaces "could" co-exist.

> 
> Yours,
> Linus Walleij