chassis_control.py in skeleton
bradleyb at fuzziesquirrel.com
Tue Dec 5 21:19:42 AEDT 2017
> 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
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
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
4 - etc...
systemd is already very good at these things.
> Let me study on them, and maybe submit some codes for your review?
> Yong Li
> -----Original Message-----
> From: bradleyb at bajor.fuzziesquirrel.com [mailto:bradleyb at bajor.fuzzie
> squirrel.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-
> 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/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=
More information about the openbmc