* chassis_control.py in skeleton @ 2017-11-23 5:38 Yong Li 2017-11-28 20:52 ` Brad Bishop 0 siblings, 1 reply; 7+ messages in thread From: Yong Li @ 2017-11-23 5:38 UTC (permalink / raw) To: openbmc; +Cc: Li, Yong B 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: chassis_control.py in skeleton 2017-11-23 5:38 chassis_control.py in skeleton Yong Li @ 2017-11-28 20:52 ` Brad Bishop 2017-11-29 1:40 ` Yong Li 0 siblings, 1 reply; 7+ messages in thread From: Brad Bishop @ 2017-11-28 20:52 UTC (permalink / raw) To: Yong Li; +Cc: OpenBMC Maillist, Li, Yong B > 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/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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: chassis_control.py in skeleton 2017-11-28 20:52 ` Brad Bishop @ 2017-11-29 1:40 ` Yong Li 2017-11-30 14:00 ` Brad Bishop 0 siblings, 1 reply; 7+ messages in thread From: Yong Li @ 2017-11-29 1:40 UTC (permalink / raw) To: 'Brad Bishop'; +Cc: 'OpenBMC Maillist' 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@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.li@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/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= ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: chassis_control.py in skeleton 2017-11-29 1:40 ` Yong Li @ 2017-11-30 14:00 ` Brad Bishop 2017-12-01 5:20 ` Yong Li 0 siblings, 1 reply; 7+ messages in thread From: Brad Bishop @ 2017-11-30 14:00 UTC (permalink / raw) To: Yong Li; +Cc: 'OpenBMC Maillist' 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/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= ^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: chassis_control.py in skeleton 2017-11-30 14:00 ` Brad Bishop @ 2017-12-01 5:20 ` Yong Li 2017-12-05 10:19 ` Brad Bishop 0 siblings, 1 reply; 7+ messages in thread From: Yong Li @ 2017-12-01 5:20 UTC (permalink / raw) To: 'Brad Bishop'; +Cc: 'OpenBMC Maillist' 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: bradleyb@bajor.fuzziesquirrel.com [mailto:bradleyb@bajor.fuzziesquirrel.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/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= ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: chassis_control.py in skeleton 2017-12-01 5:20 ` Yong Li @ 2017-12-05 10:19 ` Brad Bishop 2017-12-07 8:41 ` Yong Li 0 siblings, 1 reply; 7+ messages in thread From: Brad Bishop @ 2017-12-05 10:19 UTC (permalink / raw) To: Yong Li; +Cc: 'OpenBMC Maillist' 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= ^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: chassis_control.py in skeleton 2017-12-05 10:19 ` Brad Bishop @ 2017-12-07 8:41 ` Yong Li 0 siblings, 0 replies; 7+ messages in thread From: Yong Li @ 2017-12-07 8:41 UTC (permalink / raw) To: 'Brad Bishop'; +Cc: 'OpenBMC Maillist' Thanks Brad for your comments! My replies started with [YONG LI] below. Thanks, Yong -----Original Message----- From: bradleyb@bajor.fuzziesquirrel.com [mailto:bradleyb@bajor.fuzziesquirrel.com] On Behalf Of Brad Bishop Sent: Tuesday, December 5, 2017 6:20 PM To: Yong Li <yong.b.li@linux.intel.com> Cc: 'OpenBMC Maillist' <openbmc@lists.ozlabs.org> Subject: Re: chassis_control.py in skeleton 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? [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 > > 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 > 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 op-wait-power-on@.service 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. > > 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= ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-12-07 8:52 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-11-23 5:38 chassis_control.py in skeleton Yong Li 2017-11-28 20:52 ` Brad Bishop 2017-11-29 1:40 ` Yong Li 2017-11-30 14:00 ` Brad Bishop 2017-12-01 5:20 ` Yong Li 2017-12-05 10:19 ` Brad Bishop 2017-12-07 8:41 ` Yong Li
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.