chassis_control.py in skeleton

Brad Bishop bradleyb at fuzziesquirrel.com
Fri Dec 1 01:00:30 AEDT 2017


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=


More information about the openbmc mailing list