add a new yaml interface definition

add a new yaml interface definition

[Mahesh Kurapati]

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

Hello,

Thank you for the video on the phosphor-dbus-interfaces<https://github.com/openbmc/phosphor-dbus-interfaces> architecture.  It clarified the development flow.

I am trying to expose some of the discrete GPIO signals, 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

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

Re: add a new yaml interface definition

[Patrick Williams]

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

On Mon, Jan 04, 2021 at 09:14:19PM +0000, Mahesh Kurapati wrote:
> Hello,
Hi Mahesh,

> I am trying to expose some of the discrete GPIO signals, 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.

You can use 'devtool modify phosphor-dbus-interface' to modify it within
a yocto / bitbake environment.  `devtool` is a common tool from Yocto
you can use to modify any recipe's source temporarily in your build
environment.

You should not need to modify sdbusplus itself for this, only
phosphor-dbus-interface.

There is one catch for adding a new interface.  We are using Meson now
and Meson needs to be told how to run `sdbus++` against your YAML to
create all the cpp/hpp parts.  There is a script `gen/regenerate-meson`
to assist with this but it needs to be able to find a copy of `sdbus++`.

What should work is:

   1. `devtool modify phosphor-dbus-interface`
   2. `cd workspace/sources/phosphor-dbus-interface`
   3. `meson subprojects download`
   4. << add your YAML file >>
   5. `gen/regenerate-meson`

The step 3 is the magic which will download sdbusplus into a
subdirectory inside the repository so that `regenerate-meson` finds it.

Let me know if you run into any trouble.

-- 
Patrick Williams

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

RE: add a new yaml interface definition

[Mahesh Kurapati]

Hello Patrick, 

Thank you for the quick reply.  Step 3 fails. 

   3. `meson subprojects download`

ixia@ubuntu:~/git/development/openbmc/build/fender/workspace/sources/phosphor-dbus-interfaces$ meson subprojects download
Error during basic setup:

[Errno 2] No such file or directory: '/home/ixia/git/development/openbmc/build/fender/workspace/sources/phosphor-dbus-interfaces/download'
ixia@ubuntu:~/git/development/openbmc/build/fender/workspace/sources/phosphor-dbus-interfaces$ ls
com  gen  LICENSE  MAINTAINERS  meson.build  meson_options.txt  org  README.md  subprojects  xyz

thank you, 
Mahesh

-----Original Message-----
From: Patrick Williams <patrick@stwcx.xyz> 
Sent: Monday, January 4, 2021 4:22 PM
To: Mahesh Kurapati <mahesh.kurapati@keysight.com>
Cc: openbmc@lists.ozlabs.org
Subject: Re: add a new yaml interface definition

[EXTERNAL]

Re: add a new yaml interface definition

[Patrick Williams]

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

On Mon, Jan 04, 2021 at 11:05:18PM +0000, Mahesh Kurapati wrote:
> Hello Patrick, 
> 
> Thank you for the quick reply.  Step 3 fails. 
> 
>    3. `meson subprojects download`
> 
> ixia@ubuntu:~/git/development/openbmc/build/fender/workspace/sources/phosphor-dbus-interfaces$ meson subprojects download
> Error during basic setup:

> [Errno 2] No such file or directory: '/home/ixia/git/development/openbmc/build/fender/workspace/sources/phosphor-dbus-interfaces/download'

I'm guessing your Meson version is older than 0.49 then?  That is where
the 'download' subcommand was added according to:

https://mesonbuild.com/Subprojects.html#download-subprojects

Can you use 'pip' to install a newer one if your distro doesn't have a
newer version available?  The meson.build file in
phosphor-dbus-interfaces requires at least 0.54.1 anyhow, so there
aren't even instructions to otherwise download the subprojects using
meson's build flow (which is what happened before the 'download'
subcommand was added).

-- 
Patrick Williams

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

RE: add a new yaml interface definition

[Mahesh Kurapati]

Hello Patrick, 

Thank you.  Updating the meson fixed the issue, and I see the cpp, and hpp files generated. 

ixia@ubuntu:~/git/development/openbmc/build/fender/tmp/work/arm1176jzs-openbmc-linux-gnueabi/phosphor-dbus-interfaces/1.0+git999-r1/phosphor-dbus-interfaces-1.0+git999/gen/xyz/openbmc_project/Control/Alarm$ ls
client.hpp  server.cpp  server.hpp

I have two more follow-up questions on how I include this code in my server: 
1.  Does the libsdbusplus.so contain the methods that I defined in the Alarm.interface.yaml file?  I thought it would.  But, I don't see build time stamp changed for it.  I thought, all I need to do is include the header file in my server code, and link the server with libsdbusplus.so.  

2.  I see that in the example/Calculator_server.cpp file, both the generated cpp, and herder files are included.  While the corresponding server and header are not included in the x86_power_control.cpp server.  I see that in x86 server code, namespace is referred again.  Is that the reason why they are not included?  

Please help. 

Thank you
Mahesh

-----Original Message-----
From: Patrick Williams <patrick@stwcx.xyz> 
Sent: Monday, January 4, 2021 5:15 PM
To: Mahesh Kurapati <mahesh.kurapati@keysight.com>
Cc: openbmc@lists.ozlabs.org
Subject: Re: add a new yaml interface definition

[EXTERNAL]

Re: add a new yaml interface definition

[Patrick Williams]

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

On Tue, Jan 05, 2021 at 12:42:40AM +0000, Mahesh Kurapati wrote:
> Hello Patrick, 
> 
> Thank you.  Updating the meson fixed the issue, and I see the cpp, and hpp files generated. 
> 
> ixia@ubuntu:~/git/development/openbmc/build/fender/tmp/work/arm1176jzs-openbmc-linux-gnueabi/phosphor-dbus-interfaces/1.0+git999-r1/phosphor-dbus-interfaces-1.0+git999/gen/xyz/openbmc_project/Control/Alarm$ ls
> client.hpp  server.cpp  server.hpp
> 
> I have two more follow-up questions on how I include this code in my server: 
> 1.  Does the libsdbusplus.so contain the methods that I defined in the Alarm.interface.yaml file?  I thought it would.  But, I don't see build time stamp changed for it.  I thought, all I need to do is include the header file in my server code, and link the server with libsdbusplus.so.  

libsdbusplus.so does not because that comes from sdbusplus repo.
libphosphor_dbus.so does because that comes from P-D-I repo.

You should link with both libsdbusplus and libphosphor_dbus.

If you're using Meson or CMake as your build you shouldn't need to directly
add "-l" flags, because the package dependency will do it for you.
Yocto will want you to link against the versioned so files, so if you're
trying to hand-write makefiles you're probably going to have problems
with Yocto integration.

> 2.  I see that in the example/Calculator_server.cpp file, both the generated cpp, and herder files are included.  While the corresponding server and header are not included in the x86_power_control.cpp server.  I see that in x86 server code, namespace is referred again.  Is that the reason why they are not included?  
The authors of x86-power-control decided not to use the generated code
and instead hand-wrote their interfaces using the Boost::ASIO support in
sdbusplus.

I see the code using 'sdbusplus::' namespace elements which come from
the sdbusplus library but I don't see them using any of the
'sdbusplus::<TLD>' namespaces being used (ex. sdbusplus::xyz::openbmc_project)
which are the ones generated from YAML using sdbus++.

-- 
Patrick Williams

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

RE: add a new yaml interface definition

[Mahesh Kurapati]

Hello Patrick, 

Thank you.  I could implement the methods, and could test them with dbusctl, and also over http/REST/POST. 

Thank you for your timely response.  It made so much of difference in moving forward. Only one thing I need to figure out is how to automate all of this as part of my complete yocto build, so that it is taken care of in every build. 

Thank you, 
Mahesh

-----Original Message-----
From: Patrick Williams <patrick@stwcx.xyz> 
Sent: Tuesday, January 5, 2021 8:11 AM
To: Mahesh Kurapati <mahesh.kurapati@keysight.com>
Cc: openbmc@lists.ozlabs.org
Subject: Re: add a new yaml interface definition

[EXTERNAL]

Re: add a new yaml interface definition

[Ed Tanous]

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

RE: add a new yaml interface definition

[Mahesh Kurapati]

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