On Fri, Feb 16, 2024 at 10:18:59AM -0800, Luis Chamberlain wrote: > fstests specific watchdogs want to know when the full test suite will > start and end. Right now the kernel ring buffer can get augmented but we > can't know for sure if it was due to a test or some odd hardware issue > after fstests ran. This is specially true for systems left running tests in > loops in automation where we are not running things ourselves but rather just > get access to kernel logs, or for filesystem runner watdogs such as the one > in kdevops [0]. It is also often not easy to determine for sure based on > just logs when fstests check really has completed unless we have a > matching log of who spawned that test runner. Although we could keep track of > this ourselves by an annotation locally on the test runner, it is useful to > have independent tools which are not attached to the process which spawned > check to just peak into a system and verify the system's progress with > fstests by just using the kernel log. Keeping this in the test target kernel > ring buffer enables these use cases. > > This is useful for example for filesyste checker specific watchdogs like the > one in kdevops so that the watchdog knows when to start hunting for crashes > based just on the kernel ring buffer, and so it also knows when the show is > over. Why can't the runner that requires timing information in the kernel log just emit a message to the kernel log before it runs check and again immediately after completion of the check script? -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
