chassis_control.py in skeleton

[Yong Li]

Hi Brad,

Regarding the "org.openbmc" references, you are correct, there is only one in phosphor-state-manager. 
But there are some other "org.openbmc" references in other services(such as in ipmid services). I am working on the gpio/power related features design/implement, and would like to help to remove these dependences one by one.

Regarding the pgood property, It is used for power supply GOOD signal, I think one Boolean is good enough too. Currently we can implement the same as "org.openbmc" in "xyz." namespace, for replacement.

Regarding the gpio monitor, I found the phosphor-gpio-monitor is different than these power/button services in skeleton. phosphor-gpio-monitor uses these gpio pins as gpio keyboard(input device), and trigger a systemd service when there is any key input.

I want to trigger more, for examples, when there is one button(gpio input pin) is long pressed,  I want to set another gpio output pin to high, for LED ON, and then perform a force power off action. I think comepared with using systemd services, 
using sdbusplus to implement these triggered actions should be easier? 

Let me study on them, and maybe submit some codes for your review?

Thanks,
Yong Li
-----Original Message-----
From: bradleyb at bajor.fuzziesquirrel.com [mailto:bradleyb at bajor.fuzziesquirrel.com] On Behalf Of Brad Bishop
Sent: Thursday, November 30, 2017 10:01 PM
To: Yong Li <yong.b.li at linux.intel.com>
Cc: 'OpenBMC Maillist' <openbmc at lists.ozlabs.org>
Subject: Re: chassis_control.py in skeleton

On Wed, 2017-11-29 at 09:40 +0800, Yong Li wrote:
> Thanks Brad for your message!
> 
> I studied on these state-manager services, It seems that the 
> chassis_control.py can be replaced by chassis_state and host_state 
> .cpp files. I will perform some tests to check if there any changes 
> needed.
> 
> I also found that some of .cpp services  still need these apps in 
> skeleton. Below is an example, it needs the skeleton/op-
> pwrctl/power_control.obj.c:
> https://github.com/openbmc/phosphor-state-
> manager/blob/master/chassis_state_manager.cpp#L56

Nice find.  I was aware of this, just wasn't sure if it was too much information yet.  I think that is the only reference to org.openbmc in phosphor-state-manager.

This is something we punted on and needs to be addressed.  I say punted because we assumed that 'pgood' was a POWER concept and a better abstraction would be needed to accommodate other architectures.  Would you agree?  On the off chance a single boolean property is good enough for everyone, we could just move this interface to the xyz namespace.

I know that in the longer term, I'd like to see a much better abstraction around power related concepts so we can share/reuse code for things like analysis of faults, etc, so I'd be interested in hearing any ideas anyone has on that.

> 
> I would like to start to modify/rewrite these buton/power(gpio control 
> related) tools in skeleton, using C++ and sdbusplus, and support multi 
> platforms(X86). Could you share some comments/suggestions?

So for buttons, potentially we have this application called phosphor-
gpio-monitor:

github.com/openbmc/phosphor-gpio-monitor

You give it a gpio to monitor, and it runs a systemd target when the gpio changes state.  I'm hoping this application would be sufficient for implementing buttons.  It doesn't even use any YAML :-).  Can you have a look at it and let us know what you think?

> Create a new project such as power-button-manager, or add them into 
> this phosphor-state-manager?
> 
> Thanks,
> Yong Li
> 
> -----Original Message-----
> From: Brad Bishop [mailto:bradleyb at fuzziesquirrel.com]
> Sent: Wednesday, November 29, 2017 4:53 AM
> To: Yong Li <yong.b.li at linux.intel.com>
> Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>; Li, Yong B <yong.b.l 
> i at intel.com>
> Subject: Re: chassis_control.py in skeleton
> 
> 
> > On Nov 23, 2017, at 12:38 AM, Yong Li <yong.b.li at linux.intel.com>
> > wrote:
> > 
> > Hi All,
> > 
> > Based on my understanding, these chassis control/system manager 
> > related projects in skeleton should be initial/reference code, and 
> > will be
> 
> This is correct.  The intent is to remove them eventually.
> 
> The replacement for the chassis manager is https://github.com/openbmc 
> /phosphor-state-manager
> 
> The functions of the system manager have gradually been replicated 
> elsewhere.  For instance its state management functions were moved to 
> phosphor-state-manager or systemd.  Other functions were distributed 
> amongst configuration files and other applications.
> 
> They have not been removed from the current systems because they all 
> need to be scrubbed for any remaining usage.
> 
> > rewritten/reimplementation. I would like to know if there is any 
> > plan or on-going projects on them?
> 
> The plan is to scrub the existing systems and eliminate use of these 
> programs.  This means identifying any functional gaps in the 
> replacements and implementing those.  I don’t think anyone is working 
> on that at the moment.
> 
> Ideally any new layers/platforms being added would just not use these 
> programs, but I understand if that requires replacement function that 
> isn’t available and wouldn’t want that to hinder upstreaming of a new 
> platform.
> 
> If I were to begin to work on this, I would start by building images 
> for the current systems, remove these applications from the image and
> see what breaks.	
> 
> 
> > 
> > Thanks,
> > Yong Li
> 
> 
> -brad=