Re: chassis_control.py in skeleton

[Brad Bishop <bradleyb@fuzziesquirrel.com>]

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.

Excellent!  Thanks.

> 
> 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.

That will certainly make this easier.  Would you mind submitting
documentation for this new interface somewhere in phosphor-dbus-
interfaces, along with your code that implements it?

> 
> 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,  

You are correct, phosphor-gpio-monitor does not currently support
different systemd targets for short/long press.  Perhaps it could be
enhanced to do this?  I'm not sure if the underlying gpio-keys driver
supports this.  Another option would be to scrap the use of gpio-
keys/libevdev in phosphor-gpio-monitor and replace it with something
else?  Maybe the new Linux GPIO chardev?

> 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? 

Can you elaborate on how much configurability you intend to provide
here?  It is most definitely easier to put all the logic into the
application, but I think the answer here depends on your intent.  Do
you intend to:

1 - Implement something that targets a specific platform/use case.
2 - Implement something general purpose.

If you intend to do #1, that is perfectly fine but I try to encourage
#2 because it is more useful to the most people.

If you intend to do #2, you _could_ write it all in C/C++ but wouldn't
you have to implement:
 
1 - A way to express how the application should react.
2 - A way to express the dependencies between those responses.
3 - A way to express what the application should do if a response
action fails.
4 - etc...

systemd is already very good at these things.

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

Sure!

> Thanks,
> Yong Li
> -----Original Message-----
> From: bradleyb@bajor.fuzziesquirrel.com [mailto:bradleyb@bajor.fuzzie
> squirrel.com] On Behalf Of Brad Bishop
> Sent: Thursday, November 30, 2017 10:01 PM
> To: Yong Li <yong.b.li@linux.intel.com>
> Cc: 'OpenBMC Maillist' <openbmc@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@fuzziesquirrel.com]
> > Sent: Wednesday, November 29, 2017 4:53 AM
> > To: Yong Li <yong.b.li@linux.intel.com>
> > Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>; Li, Yong B
> > <yong.b.l 
> > i@intel.com>
> > Subject: Re: chassis_control.py in skeleton
> > 
> > 
> > > On Nov 23, 2017, at 12:38 AM, Yong Li <yong.b.li@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/openb
> > mc 
> > /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=