RE: add a new yaml interface definition

[Mahesh Kurapati <mahesh.kurapati@keysight.com>]

Hello Ed, 

Thank you for the guidelines.  I am also not planning to expose the GPIOs as is.  As you said I am implementing them as a service, for e.g., alarm service, and exposing the Alarm raise/clear as dbus methods. 

Regards
Mahesh 

-----Original Message-----
From: Ed Tanous <edtanous@google.com> 
Sent: Tuesday, January 5, 2021 11:28 AM
To: Mahesh Kurapati <mahesh.kurapati@keysight.com>
Cc: openbmc@lists.ozlabs.org
Subject: Re: add a new yaml interface definition

On Mon, Jan 4, 2021 at 1:42 PM Mahesh Kurapati <mahesh.kurapati@keysight.com> wrote:
>
> Hello,
>
>
>
> Thank you for the video on the phosphor-dbus-interfaces architecture.  It clarified the development flow.
>
>
>
> I am trying to expose some of the discrete GPIO signals,

We should think very carefully about if we want to expose raw GPIOs directly to dbus.  In practice, almost all GPIOs need some kind of filtering (debounce, power state filtering, minor state machine of other GPIOs) and that tends to be very difficult to model directly in a generic way.  In general, it's a much better idea to model your GPIO as a high level concept, like an LED, or a Power state controller, then expose a well defined API to dbus for that device.  That means that downstream clients can identify the GPIO interface reasonably and expose the appropriate APIs to the user.

> and methods to generate audio and visual alarms for our management software.  I will define two new yaml files describing these interfaces.  From the training video I understood that I should use the sbus++ to generate the cpp boilerplate code and make it part of the library.  I will extend my daemon code to implement the actual functionality as explained in the video.  Where I am stuck is on how do I add my yaml files to the phosphor-dbus-interfaces infrastructure?  How to do this in my yocto environment?  Please help.
>
>
>
> Thank you,
>
> Mahesh