Re: Extending phosphor-gpio-monitor to expose gpio objects on dbus

[Patrick Williams <patrick@stwcx.xyz>]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

On Thu, Jul 14, 2022 at 09:52:57PM +0000, Arvind Nandanahosur Ramesh wrote:
> Hi Everyone,

Hello Arvind,

> We have been toying with the idea of extending the phosphor-gpio-monitor to expose the the gpio objects it manages on dbus in addition to its current functionality of executing a specified systemd target. This additional functionality can be enabled by an additional parameter in the phosphor-multi-gpio-monitor.json file. Before going down the path of implementing this and upstreaming the changes, I wanted to get a sense on if this is a good or a bad idea. Essentially this would be useful for other services to query the current GPIO value of input signals over dbus or react to changes in its value. What did you all think ?

I'd say about every 6 months someone proposes a change to
phosphor-dbus-interface with the addition of a "Generic GPIO interface"
and it has always been rejected.  This has gotten to be so regular that
I should probably try to track them down in a list so the discussions
there can be easily referred to.

The two primary issues with a generic GPIO interface are:

1. Performance

GPIOs can change state quite rapidly and there are hundreds of them.
This is likely to be a problem on dbus.

2. Inadequate abstraction

Generally we do not expose low-level hardware entities directly on dbus,
because it doesn't provide any abstraction.  You're going to end up with
hard-coded names that tie some hardware GPIO name into various
applications elsewhere the software stack, which isn't great for
maintainability.  We've always suggested figuring out the software
construct that those GPIOs represent and make an adequate dbus
representation of that higher level construct.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]