* beep code manager for openbmc @ 2021-09-02 20:15 Ren, Zhikui 2021-09-02 21:58 ` Patrick Williams 0 siblings, 1 reply; 6+ messages in thread From: Ren, Zhikui @ 2021-09-02 20:15 UTC (permalink / raw) To: openbmc, Brad Bishop [-- Attachment #1: Type: text/plain, Size: 734 bytes --] Hi All, Beepcode manager is a stand-alone beep code service should be created to manage the beeper hardware, and provide D-Bus methods to expose the beeper function globally, all other services can use the beeper hardware by calling the beep methods. This package has been included in our distribution. Now we would like to upstream it and make it available to the community. https://github.com/Intel-BMC/openbmc/tree/intel/meta-openbmc-mods/meta-common/recipes-phosphor/beepcode-mgr Since it is now a very light service that only have one source file and a service file. I am wondering whether this service can go to an existing repository. If not, we would like to request a new repository for it. Thanks, Zhikui [-- Attachment #2: Type: text/html, Size: 4124 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: beep code manager for openbmc 2021-09-02 20:15 beep code manager for openbmc Ren, Zhikui @ 2021-09-02 21:58 ` Patrick Williams 2021-09-08 15:29 ` Ren, Zhikui 2021-09-08 18:08 ` Milton Miller II 0 siblings, 2 replies; 6+ messages in thread From: Patrick Williams @ 2021-09-02 21:58 UTC (permalink / raw) To: Ren, Zhikui; +Cc: openbmc, Brad Bishop [-- Attachment #1: Type: text/plain, Size: 1950 bytes --] Hi Zhikui, A few questions... On Thu, Sep 02, 2021 at 08:15:21PM +0000, Ren, Zhikui wrote: > Hi All, > > Beepcode manager is a stand-alone beep code service should be created to manage the beeper hardware, and provide D-Bus methods to expose the beeper function globally, all other services can use the beeper hardware by calling the beep methods. > > This package has been included in our distribution. Now we would like to upstream it and make it available to the community. > https://github.com/Intel-BMC/openbmc/tree/intel/meta-openbmc-mods/meta-common/recipes-phosphor/beepcode-mgr > > Since it is now a very light service that only have one source file and a service file. I am wondering whether this service can go to an existing repository. > If not, we would like to request a new repository for it. > > Thanks, > Zhikui > I see it creates dbus interfaces but I don't see them defined anywhere. Can we get that added to phosphor-dbus-interfaces? It isn't obvious to me from looking at what interfaces are there who would call it. I see various "beep code" patterns: {beepVRWatchdogTimeout, "1-5-1-2"}, {beepPSUFailure, "1-5-1-4"}, {beepCPUMIssing, "1-5-2-1"}, {beepCPUCatError, "1-5-2-2"}, {beepCPUErr2, "1-5-2-3"}, {beepVoltageMismatch, "1-5-2-4"}, {beepCPUConfigError, "1-5-2-5"}, {beepPowerFail, "1-5-4-2"}, {beepPowerGoodTimeOut, "1-5-4-4"}, How do these get triggered? Do arbitrary programs call into the "BeepCode" service when they hit their own event? This doesn't seem very maintainable; shouldn't the beepcode service react to events through some other method, similar to what is going on for Redfish events? How easily configurable would this be for someone who has a different beepcode policy than Intel's? Are you planning to update it with some JSON config or leave that as an exercise for the next user? -- Patrick Williams [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: beep code manager for openbmc 2021-09-02 21:58 ` Patrick Williams @ 2021-09-08 15:29 ` Ren, Zhikui 2021-09-14 21:18 ` Patrick Williams 2021-09-08 18:08 ` Milton Miller II 1 sibling, 1 reply; 6+ messages in thread From: Ren, Zhikui @ 2021-09-08 15:29 UTC (permalink / raw) To: Patrick Williams; +Cc: openbmc, Brad Bishop >-----Original Message----- >From: Patrick Williams <patrick@stwcx.xyz> >Sent: Thursday, September 2, 2021 2:59 PM >To: Ren, Zhikui <zhikui.ren@intel.com> >Cc: openbmc@lists.ozlabs.org; Brad Bishop <bradleyb@fuzziesquirrel.com> >Subject: Re: beep code manager for openbmc > >Hi Zhikui, > >A few questions... > >On Thu, Sep 02, 2021 at 08:15:21PM +0000, Ren, Zhikui wrote: >> Hi All, >> >> Beepcode manager is a stand-alone beep code service should be created to >manage the beeper hardware, and provide D-Bus methods to expose the >beeper function globally, all other services can use the beeper hardware by >calling the beep methods. >> >> This package has been included in our distribution. Now we would like to >upstream it and make it available to the community. >> https://github.com/Intel-BMC/openbmc/tree/intel/meta-openbmc- >mods/meta >> -common/recipes-phosphor/beepcode-mgr >> >> Since it is now a very light service that only have one source file and a service >file. I am wondering whether this service can go to an existing repository. >> If not, we would like to request a new repository for it. >> >> Thanks, >> Zhikui >> > >I see it creates dbus interfaces but I don't see them defined anywhere. Can >we get that added to phosphor-dbus-interfaces? > [Ren, Zhikui] Yes, I will submit a review on that. >It isn't obvious to me from looking at what interfaces are there who would call >it. I see various "beep code" patterns: > > {beepVRWatchdogTimeout, "1-5-1-2"}, {beepPSUFailure, "1-5-1-4"}, > {beepCPUMIssing, "1-5-2-1"}, {beepCPUCatError, "1-5-2-2"}, > {beepCPUErr2, "1-5-2-3"}, {beepVoltageMismatch, "1-5-2-4"}, > {beepCPUConfigError, "1-5-2-5"}, {beepPowerFail, "1-5-4-2"}, > {beepPowerGoodTimeOut, "1-5-4-4"}, > >How do these get triggered? Do arbitrary programs call into the "BeepCode" >service when they hit their own event? This doesn't seem very maintainable; >shouldn't the beepcode service react to events through some other method, >similar to what is going on for Redfish events? > [Ren, Zhikui] Currently, an application can call into the BeepCode by calling the dbus method One of improvement ideas is to make the beepcode service monitor the events it is interested in. >How easily configurable would this be for someone who has a different >beepcode policy than Intel's? Are you planning to update it with some JSON >config or leave that as an exercise for the next user? > [Ren, Zhikui] Good idea. However I don't have a definitive plan on that currently and open to suggestions/collaborations. >-- >Patrick Williams [Ren, Zhikui] To summarize, I think the following steps can be taken: 1. Find an existing home or create a new one for Beep code manager 2. Upstream existing code as initial check in 3. create phosphor-dbus-interfaces for it 4. update to use phosphor-dbus-interface 5. further improvements including the two discussed above Any comments/feedback? Thanks, Zhikui ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: beep code manager for openbmc 2021-09-08 15:29 ` Ren, Zhikui @ 2021-09-14 21:18 ` Patrick Williams 2021-09-20 20:14 ` Ren, Zhikui 0 siblings, 1 reply; 6+ messages in thread From: Patrick Williams @ 2021-09-14 21:18 UTC (permalink / raw) To: Ren, Zhikui; +Cc: openbmc, Brad Bishop [-- Attachment #1: Type: text/plain, Size: 2800 bytes --] On Wed, Sep 08, 2021 at 03:29:48PM +0000, Ren, Zhikui wrote: > >I see it creates dbus interfaces but I don't see them defined anywhere. Can > >we get that added to phosphor-dbus-interfaces? > > > [Ren, Zhikui] Yes, I will submit a review on that. > >It isn't obvious to me from looking at what interfaces are there who would call > >it. I see various "beep code" patterns: > > > > {beepVRWatchdogTimeout, "1-5-1-2"}, {beepPSUFailure, "1-5-1-4"}, > > {beepCPUMIssing, "1-5-2-1"}, {beepCPUCatError, "1-5-2-2"}, > > {beepCPUErr2, "1-5-2-3"}, {beepVoltageMismatch, "1-5-2-4"}, > > {beepCPUConfigError, "1-5-2-5"}, {beepPowerFail, "1-5-4-2"}, > > {beepPowerGoodTimeOut, "1-5-4-4"}, > > > >How do these get triggered? Do arbitrary programs call into the "BeepCode" > >service when they hit their own event? This doesn't seem very maintainable; > >shouldn't the beepcode service react to events through some other method, > >similar to what is going on for Redfish events? > > > [Ren, Zhikui] Currently, an application can call into the BeepCode by calling the dbus method > One of improvement ideas is to make the beepcode service monitor the events it is interested in. Fundamentally, I see this as a very poor design. I don't really like us taking code written in isolation without any design feedback and then expecting the project to pick it up as-is. We already have REDFISH_MESSAGE_ID and IPMI_SEL_* journal strings, a proposal for audit, and now this beepcode proposal, which are all a type of event. The current design proposals for all of them is that every application needs to be aware of every consumer and make N random function calls to each of those consumers. It is sloppy and doesn't scale. I don't want to add to the mess by adding beepcodes this way. I'm slowly working on unraveling this by adding an Event concept to phosphor-logging (distinct from the current Error concepts). I'm hopeful that this can be leveraged for any such event, including boot sequence states that can be consumed by this beepcode application. I should have the initial design within a week or two and would certainly welcome any review (with respect to beep code) and assistance in implementation. > >How easily configurable would this be for someone who has a different > >beepcode policy than Intel's? Are you planning to update it with some JSON > >config or leave that as an exercise for the next user? > > > [Ren, Zhikui] Good idea. However I don't have a definitive plan on that currently and open to suggestions/collaborations. Another reason why we shouldn't just take wholesale code that was written and designed in isolation but isn't really fit for anyone else's purposes. -- Patrick Williams [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: beep code manager for openbmc 2021-09-14 21:18 ` Patrick Williams @ 2021-09-20 20:14 ` Ren, Zhikui 0 siblings, 0 replies; 6+ messages in thread From: Ren, Zhikui @ 2021-09-20 20:14 UTC (permalink / raw) To: Patrick Williams; +Cc: openbmc, Brad Bishop >-----Original Message----- >From: Patrick Williams <patrick@stwcx.xyz> >Sent: Tuesday, September 14, 2021 2:18 PM >To: Ren, Zhikui <zhikui.ren@intel.com> >Cc: openbmc@lists.ozlabs.org; Brad Bishop <bradleyb@fuzziesquirrel.com> >Subject: Re: beep code manager for openbmc > >On Wed, Sep 08, 2021 at 03:29:48PM +0000, Ren, Zhikui wrote: >> >I see it creates dbus interfaces but I don't see them defined >> >anywhere. Can we get that added to phosphor-dbus-interfaces? >> > >> [Ren, Zhikui] Yes, I will submit a review on that. >> >It isn't obvious to me from looking at what interfaces are there who >> >would call it. I see various "beep code" patterns: >> > >> > {beepVRWatchdogTimeout, "1-5-1-2"}, {beepPSUFailure, "1-5-1-4"}, >> > {beepCPUMIssing, "1-5-2-1"}, {beepCPUCatError, "1-5-2-2"}, >> > {beepCPUErr2, "1-5-2-3"}, {beepVoltageMismatch, "1-5-2-4"}, >> > {beepCPUConfigError, "1-5-2-5"}, {beepPowerFail, "1-5-4-2"}, >> > {beepPowerGoodTimeOut, "1-5-4-4"}, >> > >> >How do these get triggered? Do arbitrary programs call into the >"BeepCode" >> >service when they hit their own event? This doesn't seem very >> >maintainable; shouldn't the beepcode service react to events through >> >some other method, similar to what is going on for Redfish events? >> > >> [Ren, Zhikui] Currently, an application can call into the BeepCode by >> calling the dbus method One of improvement ideas is to make the >beepcode service monitor the events it is interested in. > >Fundamentally, I see this as a very poor design. I don't really like us taking >code written in isolation without any design feedback and then expecting the >project to pick it up as-is. > >We already have REDFISH_MESSAGE_ID and IPMI_SEL_* journal strings, a >proposal for audit, and now this beepcode proposal, which are all a type of >event. The current design proposals for all of them is that every application >needs to be aware of every consumer and make N random function calls to >each of those consumers. It is sloppy and doesn't scale. I don't want to add to >the mess by adding beepcodes this way. > >I'm slowly working on unraveling this by adding an Event concept to phosphor- >logging (distinct from the current Error concepts). I'm hopeful that this can be >leveraged for any such event, including boot sequence states that can be >consumed by this beepcode application. I should have the initial design within >a week or two and would certainly welcome any review (with respect to beep >code) and assistance in implementation. > [Ren, Zhikui] Looking forward to see the review. >> >How easily configurable would this be for someone who has a different >> >beepcode policy than Intel's? Are you planning to update it with >> >some JSON config or leave that as an exercise for the next user? >> > >> [Ren, Zhikui] Good idea. However I don't have a definitive plan on that >currently and open to suggestions/collaborations. > >Another reason why we shouldn't just take wholesale code that was written >and designed in isolation but isn't really fit for anyone else's purposes. > [Ren, Zhikui] Getting feedbacks from the community was the intention of this email chain. We have some ideas how to improve the current design and make it more flexible. I will start working on a design review next. >-- >Patrick Williams ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: beep code manager for openbmc 2021-09-02 21:58 ` Patrick Williams 2021-09-08 15:29 ` Ren, Zhikui @ 2021-09-08 18:08 ` Milton Miller II 1 sibling, 0 replies; 6+ messages in thread From: Milton Miller II @ 2021-09-08 18:08 UTC (permalink / raw) To: Ren, Zhikui; +Cc: openbmc, Brad Bishop Ren, Zhikuui wrote: >Patrick Williams wrote:>>On Thu, Sep 02, 2021 at 08:15:21PM +0000, Ren, Zhikui wrote: >>> Hi All, >>> >>> Beepcode manager is a stand-alone beep code service should be >created to >>manage the beeper hardware, and provide D-Bus methods to expose the >>beeper function globally, all other services can use the beeper >hardware by >>calling the beep methods. >>> >>> This package has been included in our distribution. Now we would >like to >>upstream it and make it available to the community. >>> >>> >>> Since it is now a very light service that only have one source >file and a service >>file. I am wondering whether this service can go to an existing >repository. >>> If not, we would like to request a new repository for it. >>> My thought is perhaps with our progress code logging and 7-segment post code display in phosphor-host-postd ? I could see several of the events mentioned be triggered by writing a post code, and there are already a few separate programs in that repository, one to record codes and one to display on some 7-segment led hardware. The phosphor-post-code-manager which records the history is in its own repository (before the desire to combine them). I'm certianally open to other suggestions just thought I'd plant a seed for discussion. >>> Thanks,>>> Zhikui >>> [various other discussions on interfaces , making the beep codes configurable , etc] >[Ren, Zhikui] To summarize, I think the following steps can be taken:>1. Find an existing home or create a new one for Beep code manager >2. Upstream existing code as initial check in >3. create phosphor-dbus-interfaces for it >4. update to use phosphor-dbus-interface >5. further improvements including the two discussed above > >Any comments/feedback? > >Thanks, >Zhikui milton ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-09-20 20:18 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-02 20:15 beep code manager for openbmc Ren, Zhikui 2021-09-02 21:58 ` Patrick Williams 2021-09-08 15:29 ` Ren, Zhikui 2021-09-14 21:18 ` Patrick Williams 2021-09-20 20:14 ` Ren, Zhikui 2021-09-08 18:08 ` Milton Miller II
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).