dbus-sensors

[Matt Spinler]

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?
>>
>> 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.