Date: Wed, 30 Jul 2003 19:23:04 -0500 From: Sean Kelly <smkelly@FreeBSD.org> To: arch@freebsd.org Subject: A working watchdog API Message-ID: <20030731002304.GA5131@edgemaster.zombie.org>
next in thread | raw e-mail | index | archive | help
After some thought and my thread over the HW_WDOG option, I have come up with a proposal for a new watchdog API and am looking for comments and ideas from people who actually use and implement hardware watchdog drivers. First up, unless somebody says otherwise to me, I plan to commit a patch shortly to remove the HW_WDOG option from 5.x as discussed in my previous thread. You can review the patch here if you wish: http://www.sean-kelly.org/hw_wdog.diff Now that HW_WDOG is no longer functional and going away, it seems to me that a better interface needs to exist for watchdogs. In my opinion, this interface needs to be more robust, long-lasting, and require less coding for watchdog driver developers. Therefore, I propose a new watchdog type. Something along the lines of: typedef struct _watchdog_t { char name[16]; int flags; int (*enable)(int seconds); int (*disable)(); int (*tickle)(); /* Add more to me! */ } watchdog_t; Possible 'flags' could include CAN_DISABLE, to differentiate between watchdogs that can and can not be disabled. If a watchdog can't be disabled, then it will be necessary to tickle it during activities such as a crashdump instead of disabling it instead. I'm not sure you'd ever want to disable it in the first place anyway... If we wanted to support multiple watchdogs in a single system, then a simple linked list could be made of all the filled out 'watchdog_t's. The only semi-complex part would be determining the lowest necessary 'tickle' frequency to keep them all happy. Functions such as watchdog_enable(), watchdog_disable(), watchdog_tickle() would provide a standardized interface across the entire kernel source tree for maintaining watchdog state. For example: int watchdog_tickle() { /* This could be a loop through many watchdogs */ if (watchdog->tickle != NULL) (*watchdog->tickle)(); } For systems with no hardware watchdog, it would be possible to use my software watchdog code. That code could be easily wrapped up inside this API, thus putting all the watchdog family under a nice little umbrella. Comments? Ideas? Questions? Death threats? -- Sean Kelly | PGP KeyID: D2E5E296 smkelly@FreeBSD.org | http://www.sean-kelly.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030731002304.GA5131>