On Mon, Aug 03, 2015 at 07:13:26PM -0700, Guenter Roeck wrote:
- Some watchdogs have a very short maximum timeout, in the range of just a few
seconds. Such low timeouts are difficult if not impossible to support from
user space. Drivers supporting such watchdog hardware need to implement
a timer function to augment heartbeats from user space.
- A new status flag, WDOG_RUNNING, informs the watchdog subsystem that a
watchdog is running, and that the watchdog subsystem needs to generate
heartbeat requests while the associated watchdog device is closed.
Patch #2 adds timer functionality to the watchdog core. It solves the problem
of short maximum hardware timeouts by augmenting heartbeats triggered from
user space with internally triggered heartbeats.
Patch #3 adds functionality to generate heartbeats while the watchdog device is
closed. It handles situation where where the watchdog is running after
the driver has been instantiated, but the device is not yet opened,
and post-close situations necessary if a watchdog can not be stopped.
These sound concerning because it seems that heartbeats could be generated
outside of the direct control of userspace. I have a program that depends
on having direct control over whether heartbeats are generated (or more
specifically, *not* generated.) If these new features introduce a new way
for heartbeats to be generated, is there a way I can detect or disable
that behavior from userspace? Unwanted heartbeats could break my program
and may lead to data corruption.
A related issue from some years ago is the unfortunate fact that closing
the watchdog device also generates a heartbeat. I'd like to disable that
also, and submitted a patch for it here:
http://www.spinics.net/lists/linux-watchdog/msg01477.html