Re: Diagnostics

On 19/10/2024 00:30, Don Y wrote:

Hi George,
 [Hope all is well with you and at home]
 On 10/18/2024 2:42 PM, George Neuner wrote:

WRT Don's question, I don't know the answer, but I suspect runtime
diagnostics are /not/ routinely implemented for devices that are not
safety critical.  Reason: diagnostics interfere with operation of
<whatever> they happen to be testing.  Even if the test is at low(est)
priority and is interruptible by any other activity, it still might
cause an unacceptable delay in a real time situation.

 But, if you *know* when certain aspects of a device will be "called on",
you can take advantage of that to schedule diagnostics when the device is
not "needed".  And, in the event that some unexpected "need" arises,
can terminate or suspend the testing (possibly rendering the effort
moot if it hasn't yet run to a conclusion).
 E.g., I scrub freed memory pages (zero fill) so information doesn't
leak across protection domains.  As long as some minimum number
of *scrubbed* pages are available for use "on demand", why can't
I *test* the pages yet to be scrubbed?

You /could/ do that, but what is the point?
What are you checking for?  What is the realistic likelihood of finding a problem, and what are the consequences of such a problem?  How do you test your test routines - are you able to simulate the problem you are testing in a good enough manner?  What are the circumstances that could lead to a fault that you detect with the tests but where you would not already see the problem in other ways?  Is it realistic to assume that your diagnostic test and reporting systems are able to run properly when the this problem occurs?  If some kind of problem actually occurs, will your tests realistically identify it?
/Those/ are the kinds of questions you should be asking before putting in some kind of tests.  They are the important questions.  Asking "why can't I do a test now?" is peanuts in comparison.