chassis_control.py in skeleton

[Yong Li]

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

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?
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.li 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=