Discussion on GPIO monitoring and design thoughts.

[Andrew Jeffery]

Hi Vishwa,

I have some queries below. Apologies if they appear curt, but I'm
trying to cut to the point in each case.

On Wed, 2017-04-05 at 13:56 +0530, vishwa wrote:
> We had a technical discussion on HOWTO and what is the right thing to do 
> handling the GPIO assertion and here is the gist.
> 
> 1) Use gpio-keys and utilize libevdev wrappers ( 
> https://www.freedesktop.org/software/libevdev/doc/latest/ ) to watch for 
> data in /dev/input/event.

Okay, I'd like you to step back and detail what problem you're actually
trying to solve here. Going from wanting to handle GPIO interrupts to
using gpio-keys everywhere needs some explanation. We have at least two
other interfaces that would appear to be sufficient: GPIO chardev and
sysfs.

What you've described reads to me like a case of the X-Y problem. This
link is rather blunt, but it illustrates the issue: 

http://mywiki.wooledge.org/XyProblem

> 
> 2) Define a target with set of services that would be called into by the 
> GPIO monitor application when the GPIO state changes to what is expected.
> 
>   - 2.1) Another option was to just broadcast a signal that interested 
> parties could catch and act

I assume this is on D-Bus?

>  but then it was not chosen because there 
> would be no guarantee that the signal would ever be delivered / caught 
> by needed parties.

Isn't this what systemd is for?

Isn't this what you gain by decoupling the monitoring from the
handling? For instance if we're talking in abstract terms, the current
system policy might be to not care about the state change.

> 
>   - 2.2 ) Also going the signal way demands a service that just needs to 
> watch for that.

Is that the case? Can't we have one service handling multiple signals?
Whether that's a good idea is another question.

> 
> *) The services that are part of the target will then own complete 
> handling of the condition instead of the application that monitored the 
> GPIO.

Why are we decoupling the handler services from the GPIO? What is the
advantage?

The disadvantage is the behaviour of the system is much harder to
understand. If we go this route, what tooling will be in place to debug
failures of interactions between components?

I would argue that this is already a significant hurdle in
understanding integration failures on the BMC, and I would prefer not
to add to the problems.

> 
> ---------
> 
> Here is an example of application that handles the GPIO assertion that 
> happens when host does a checkstop.
> 
> 1) Application's arguments need /dev/input/event<$number> and the 
> expected GPIO state as indicated by linux,code in :
> 
> http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/gpio-keys.txt

There is a downside in that you will be creating a kernel ABI by
mapping GPIO events to a keycode. This choice appears to me to be
arbitrary, and from the kernel's perspective we don't know how
userspace is going to treat the value so we lose the flexibility to
change it if it's not. This isn't a show-stopper, but it sure feels
like a wart that doesn't need to exist.

> 
> 2) Call this app after reaching `Host-Running` state thus avoiding any 
> checks to see current state.
> 
> 2) App will then use libevdev wrappers to watch for the state

It bothers me that we'd be invoking libevdev to catch an interrupt on a
GPIO. It seems unnecessarily complex in general.

> 
> 3) On seeing the expected state change, app calls into the configured 
> target.
> 
> 4) Configured target right now has 2 services.
> 
>    - 4.1 ) Service that Creates an errorlog indicating the checkstop
>    - 4.2 ) Service that will start the Quiesce target
> 
> --------
> 
> This design direction helps decouple applications that monitor and 
> analyze the conditions.

Sure. But you need to describe the advantage of decoupling these
concepts. Why do we need the abstraction? I need something more than
"decoupling is good", because as described above it can lead to a lot
of overhead trying to track down bugs. Sometimes it's a balancing act,
and we need to understand what we're trading off.

Cheers,

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170407/81e8032b/attachment.sig>