On Mon, Feb 19, 2024 at 02:42:32PM +1100, Dave Chinner wrote: > 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? That's exactly what is done today, it just seemed to me that since this has been useful to a test runner now for years, it might make sense to generalize this. Luis
