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

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

[Arvind Nandanahosur Ramesh]

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

Hi Everyone,

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 ?

Thanks
Arvind


[-- Attachment #2: Type: text/html, Size: 2424 bytes --]

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

[Patrick Williams]

[-- 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 --]

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

[Andrew Jeffery]

On Sun, 17 Jul 2022, at 20:28, Patrick Williams wrote:
> 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.

I did a bit of digging and pushed this:

https://gerrit.openbmc.org/c/openbmc/docs/+/55422

Andrew

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

[Michael Richardson]

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


Patrick Williams <patrick@stwcx.xyz> wrote:
    > 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.

So, clearly some developers think that they need this :-)

I read:
   https://gerrit.openbmc.org/c/openbmc/docs/+/55422

and this is good, but is little too abstract to be useful I think.

I would like to suggest three things.
1) link to some situations where this has been proposed, and then a smarter
resolution via another method might be good.  Is there a link to the
host-power on code as a clear commit?

2) I wonder about situations where developers are trying to get access to
some kind of debug info into the field, and that's why they look this.  That
is, there isn't a way to wrap it up into something abstract, because the
point is to allow for deeper examination.

3) maybe link to situations where dbus has failed to be fast enough.


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

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

[Andrew Jeffery]

Hi Michael,

On Mon, 18 Jul 2022, at 19:40, Michael Richardson wrote:
> Patrick Williams <patrick@stwcx.xyz> wrote:
>     > 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.
>
> So, clearly some developers think that they need this :-)
>
> I read:
>    https://gerrit.openbmc.org/c/openbmc/docs/+/55422
>
> and this is good, but is little too abstract to be useful I think.

Can you please provide this feedback as comments on https://gerrit.openbmc.org/c/openbmc/docs/+/55422? This way we can ensure all commentary is addressed before submitting the patch.

Thanks,

Andrew

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

[Andrew Jeffery]

Sorry, I hit "Reply to List" rather than "Reply to All"

On Tue, 19 Jul 2022, at 08:59, Andrew Jeffery wrote:
> Hi Michael,
>
> On Mon, 18 Jul 2022, at 19:40, Michael Richardson wrote:
>> Patrick Williams <patrick@stwcx.xyz> wrote:
>>     > 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.
>>
>> So, clearly some developers think that they need this :-)
>>
>> I read:
>>    https://gerrit.openbmc.org/c/openbmc/docs/+/55422
>>
>> and this is good, but is little too abstract to be useful I think.
>
> Can you please provide this feedback as comments on 
> https://gerrit.openbmc.org/c/openbmc/docs/+/55422? This way we can 
> ensure all commentary is addressed before submitting the patch.
>
> Thanks,
>
> Andrew