chassis_control.py in skeleton
Hi All,
Based on my understanding, these chassis control/system manager related projects in skeleton should be initial/reference code, and will be rewritten/reimplementation. I would like to know if there is any plan or on-going projects on them?
Thanks,
Yong Li
Quoted 7 lines · Yong Li
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.
Quoted 2 lines
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.
Quoted 3 lines
Thanks,
Yong Li
-brad
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:[email protected]]
Sent: Wednesday, November 29, 2017 4:53 AM
To: Yong Li <[email protected]>
Cc: OpenBMC Maillist <[email protected]>; Li, Yong B <[email protected]>
Subject: Re: chassis_control.py in skeleton
Quoted 7 lines · Yong Li
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.
Quoted 2 lines
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.
Quoted 3 lines
Thanks,
Yong Li
-brad=
Quoted 7 lines · Yong Li
Thanks Brad for your message!
I studied on these state-manager services, It seems that the
chassis_control.pycan be replaced bychassis_stateandhost_state.cpp files. I will perform some tests to check if there any changes needed.
Quoted 5 lines
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.
Quoted 5 lines
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?
Quoted 62 lines
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:[email protected]]
Sent: Wednesday, November 29, 2017 4:53 AM
To: Yong Li <[email protected]>
Cc: OpenBMC Maillist <[email protected]>; Li, Yong B <yong.b.l [email protected]>
Subject: Re:chassis_control.pyin skeletonQuoted 8 lines
On Nov 23, 2017, at 12:38 AM, Yong Li <[email protected]> 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-managerThe 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.
Quoted 3 lines
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.
Quoted 3 lines
Thanks,
Yong Li-brad=
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: [email protected] [mailto:[email protected]] On Behalf Of Brad Bishop
Sent: Thursday, November 30, 2017 10:01 PM
To: Yong Li <[email protected]>
Cc: 'OpenBMC Maillist' <[email protected]>
Subject: Re: chassis_control.py in skeleton
Quoted 7 lines · Yong Li
Thanks Brad for your message!
I studied on these state-manager services, It seems that the
chassis_control.pycan be replaced bychassis_stateandhost_state.cpp files. I will perform some tests to check if there any changes needed.
Quoted 5 lines
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.
Quoted 4 lines
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?
Quoted 61 lines
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:[email protected]]
Sent: Wednesday, November 29, 2017 4:53 AM
To: Yong Li <[email protected]>
Cc: OpenBMC Maillist <[email protected]>; Li, Yong B <yong.b.l [email protected]>
Subject: Re:chassis_control.pyin skeletonQuoted 8 lines
On Nov 23, 2017, at 12:38 AM, Yong Li <[email protected]> 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-managerThe 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.
Quoted 2 lines
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.
Quoted 3 lines
Thanks,
Yong Li-brad=
Hi Brad,
Quoted 7 lines
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.
Quoted 5 lines
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?
Quoted 8 lines
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?
Quoted 5 lines
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.
Quoted 2 lines
Let me study on them, and maybe submit some codes for your review?
Sure!
Quoted 133 lines
Thanks,
Yong Li
-----Original Message-----
From: [email protected] [mailto:[email protected] squirrel.com] On Behalf Of Brad Bishop
Sent: Thursday, November 30, 2017 10:01 PM
To: Yong Li <[email protected]>
Cc: 'OpenBMC Maillist' <[email protected]>
Subject: Re:chassis_control.pyin skeletonQuoted 8 lines · Yong Li
Thanks Brad for your message!
I studied on these state-manager services, It seems that the
chassis_control.pycan be replaced bychassis_stateandhost_state.cpp files. I will perform some tests to check if there any changes
needed.Quoted 5 lines
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#L56Nice 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.
Quoted 6 lines
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?
Quoted 75 lines
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:[email protected]]
Sent: Wednesday, November 29, 2017 4:53 AM
To: Yong Li <[email protected]>
Cc: OpenBMC Maillist <[email protected]>; Li, Yong B <yong.b.l
[email protected]>
Subject: Re:chassis_control.pyin skeletonQuoted 9 lines
On Nov 23, 2017, at 12:38 AM, Yong Li <[email protected]> wrote:
Hi All,
Based on my understanding, these chassis control/system manager related projects in skeleton should be initial/reference code, and
will beThis is correct. The intent is to remove them eventually.
The replacement for the chassis manager is https://github.com/openb
mc
/phosphor-state-managerThe 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.Quoted 2 lines
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.Quoted 3 lines
Thanks,
Yong Li-brad=
Thanks Brad for your comments! My replies started with [YONG LI] below.
Thanks,
Yong
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Brad Bishop
Sent: Tuesday, December 5, 2017 6:20 PM
To: Yong Li <[email protected]>
Cc: 'OpenBMC Maillist' <[email protected]>
Subject: Re: chassis_control.py in skeleton
Hi Brad,
Quoted 7 lines
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.
Quoted 4 lines
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?
[YONG LI] Will do, I would like to start from the simpler changes first. For example, adding pgood to the .yaml, and implement the property
Quoted 8 lines
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?
[YONG LI] Will check/test if there is any new solution for the gpio interrupt handing
Quoted 4 lines
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.
[YONG LI] Currently I am testing the system using Intel platforms. The current power on/off services are not match the hardware.
For example, our hardware needs not only the PS_GOOD signal, but and other signals to check if the host on(ACPI status, CPU power signals), and there are several different error handing processes. On first thought, I want to implement all these logic in one single service. Based on your comments, it seems that I can split these checking to several different services, and using systemd to connect them together. Every service should be simple and easy to implement, The [email protected] is an example, it just wait for pgood signal.
We can just install these needed services on different platforms. For example, power button monitor service is installed on both IA and openpower platforms, but ACPI monitor is installed on IA platforms only.
Quoted 2 lines
Let me study on them, and maybe submit some codes for your review?
Sure!
Quoted 118 lines
Thanks,
Yong Li
-----Original Message-----
From: [email protected] [mailto:[email protected] squirrel.com] On Behalf Of Brad Bishop
Sent: Thursday, November 30, 2017 10:01 PM
To: Yong Li <[email protected]>
Cc: 'OpenBMC Maillist' <[email protected]>
Subject: Re:chassis_control.pyin skeletonQuoted 7 lines · Yong Li
Thanks Brad for your message!
I studied on these state-manager services, It seems that the
chassis_control.pycan be replaced bychassis_stateandhost_state.cpp files. I will perform some tests to check if there any changes needed.Quoted 5 lines
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#L56Nice 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.
Quoted 5 lines
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?
Quoted 62 lines
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:[email protected]]
Sent: Wednesday, November 29, 2017 4:53 AM
To: Yong Li <[email protected]>
Cc: OpenBMC Maillist <[email protected]>; Li, Yong B <yong.b.l [email protected]>
Subject: Re:chassis_control.pyin skeletonQuoted 8 lines
On Nov 23, 2017, at 12:38 AM, Yong Li <[email protected]> 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-managerThe 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.
Quoted 2 lines
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.Quoted 3 lines
Thanks,
Yong Li-brad=