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