On Fri, Feb 05, 2016 at 03:13:52PM -0600, Kyle Roeschley wrote:
> On Fri, Feb 05, 2016 at 02:08:03PM -0600, Josh Cartwright wrote:
> > On Thu, Feb 04, 2016 at 07:28:02PM -0600, Kyle Roeschley wrote:
[..]
> > This is...strange.  You're allowing a user to enable an interrupt reset
> > action, but...there is no way that a user can actually _do_ anything
> > when that action occurs.
> > 
> > I'm reminded of one of these:
> > 
> >   https://www.youtube.com/watch?v=aqAUmgE3WyM
> > 
> > (The only reason I can think of where this would be a legitimate thing
> > to do was if we were relying on the watchdog interrupt to bring the CPU
> > out of a low power state...but AFAIK that's not something we do).
> > 
> >   Josh
> 
> This is another reason (that I forgot to mention) for this being an RFC.
> Ideally we'd poll or select the /dev/watchdogN file to wait on interrupt, but
> this isn't supported by the watchdog core. My next instinct would be to have an
> sysfs attribute named interrupt or event which a user could read/poll/select
> to look for a 1 value indicating that an interrupt has occurred. Else, maybe
> polling support could be added to the core, but I don't expect it would be very
> useful.

There are already plenty of timer interfaces a user can use for managing
timeouts.  We don't need to invent another one.

Now, we did enumerate what might be a legitimate use case, which is when
an external signal is being used to feed/pet/kick, but that
functionality isn't supported in the cRIO/cDAQ case, so it shouldn't be
included in your patchset.

  Josh