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
Attachment:
signature.asc
Description: PGP signature
