Re: [2/2] niwatchdog: add support for custom ioctls

[Kyle Roeschley <kyle.roeschley@ni.com>]

On Thu, Feb 04, 2016 at 12:38:44PM -0600, Josh Cartwright wrote:
> On Thu, Feb 04, 2016 at 08:38:10AM -0800, Guenter Roeck wrote:
> > >realize that users may not care about differences of less than a second, but it
> > >seems better to err on the side of caution and provide more accuracy than
> > >they would be expected to need. For instance, this watchdog operates on a
> > >real-time system with any number of industrial applications which could require
> > >high accuracy even from the watchdog.
> >
> > I don't really believe that this is or will ever be the case. I would argue that
> > any system which requires such a high accuracy for a watchdog timeout has a severe
> > architectural problem. After all, we are not talking about reaction time to an
> > external or internal event here. We are talking about what should happen if
> > something goes wrong so badly that it results in an immediate system reboot
> > or hardware reset.
> 
> I think we're pushing on what the definition of a "watchdog" is, and
> it's purpose is within a wider system.  Historically, the kernels' usage
> of "watchdog" meant some hardware which would facilitate a reset of the
> system if not fed/pet in a timely manner.  In this case, I'd definitely
> agree with your statement that sub-millisecond timing is overkill and/or
> a poor design.
> 
> For our "watchdog" hardware, however, resetting the hardware/CPU state
> is only _one_ possible action that can be configured to occur when the
> timer expires.
> 
> But other actions exist too.  In the most timing-sensitive case, our
> "watchdog" is attached to to an external trigger bus, which carries
> trigger signals equidistantly to a series of data acquisition devices
> (or other plug-in measurement devices).  The "watchdog" can be
> configured to signal one or several of these trigger lines (triggering
> synchronized acquisition or whatever) in the case of expiration.
> 
> In this way, it's much more like a general user configurable countdown
> timer than it is a "watchdog" in the Linux sense.  The question is
> whether or not WATCHDOG_CORE should grow to include some of the
> functionality required, or if that functionality should live somewhere
> else.  (And if the answer is "somewhere else", how can we _also_
> implement the standard watchdog interface for the case where we want
> hardware reset to be the configured action).
> 

To this point, the current idea was to use sysfs attributes "action_reset"
(which is on by default), "action_interrupt" (which is off by default), and
"counter" (to directly read/write the counter value). However, we run into the
locking problem that I mentioned in my last email. Anyone have any ideas on
that?

Regards,

Kyle Roeschley