> A chain can request to kill the registering process if the interval > elapses. In this case a restarted process can register with the > driver giving the same identifier and reset the chain. This is the > main reason why there is no association between chains and processes > or open device files. How do genuinely unused chains get automatically cleaned up > Possible chain actions: > - ACTION_SIGNAL: sends a configurable signal to the process > - ACTION_KILL: sends the SIGKILL signal to the process These two are the same (detail) > starting point to integrate it? As this "chain API" would controlled > through ioctl() calls maybe drivers/watchdog/watchdog_dev.c would be > a good place... or a drivers/watchdog/watchdog_chain.c which gets the > ioctl calls, watchdog_dev.c couldn't parse ... It doesn't actually seem to have any connection at all with the kernel watchdog drivers. I don't mean that as a criticism but what you are describing seems to be some kind of software timer groups. If you wanted to link it to a real watchdog presumably you'd just put the watchdog pinging user space process in a group and set it to get killed if the group triggered. I'm not sure I understand why it can't be done cleanly in userspace either. If you have a daemon accepting unix domain connections then it can get the pid of the other end and can kill it, or monitor incoming packets and requests from it. If that process is also the one pinging the hardware watchdog it can provide reboot protection against its own crashing. It can also do much more flexible and interesting policy things like only pinging the watchdog each time all the clients check in. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
