dbus-sensors

[James Feist]

On 4/22/2020 9:01 AM, Matt Spinler wrote:
> 
> 
> On 4/22/2020 7:24 AM, Brad Bishop wrote:
>> at 8:11 AM, Patrick Williams <patrick at stwcx.xyz> wrote:
>>
>>> On Wed, Apr 22, 2020 at 07:56:14AM -0400, Brad Bishop wrote:
>>>> at 5:54 PM, James Feist <james.feist at linux.intel.com> wrote:
>>>>>> 3. After creating this event log, make sure not to do it again until
>>>>>>    main power is cycled.
>>>>>
>>>>> I'd rather this be until the status goes OK again.
>>>>
>>>> We have user-experience requirements that the server administrator 
>>>> must be
>>>> “nagged” in this fashion when something is broken like this. Could the
>>>> behavior be selectable via build switch?  Any other ideas on how to
>>>> accommodate both behaviors?

As long as it's configurable somehow, fine by me.

>>>
>>> This sounds like a form of error filtering.  Shouldn't that decision be
>>> done at a much higher level in the stack than down in the entity that
>>> reads the hardware sensor?
>>
>> Thats an interesting thought.  When the error reporting code sees the 
>> error for the first time, it could maintain a list of errors that it 
>> needs to “replay” at different system events, like when the server 
>> powers on.
> 
> It isn't really nagging, it's more like error throttling.  At most, only 
> log one error per power cycle.
> I have to check still, but we may also need to still log the other 
> errors, just with a
> different severity (for debug purposes).
> 
> I kinda like this filtering idea too.  It is flexible and we would only 
> have to do it in one place as
> opposed to in all the sensor applications we end up using, and could 
> also be used to change the
> event log severities as mentioned above.  We will have to make sure when 
> creating the event log
> that it contains enough information to recognize the device that is 
> failing so that we can filter
> appropriately.
> 
> 
>>
>> This is certainly more flexible and I like the idea - but one down 
>> side though is the logging code becomes stateful and the complexity is 
>> slightly higher.
>