From owner-freebsd-arch@FreeBSD.ORG Wed Jul 30 17:23:07 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 317A737B401 for ; Wed, 30 Jul 2003 17:23:07 -0700 (PDT) Received: from area51.slashnet.org (area51.slashnet.org [209.150.101.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id A767D43F3F for ; Wed, 30 Jul 2003 17:23:06 -0700 (PDT) (envelope-from smkelly@FreeBSD.org) Received: from edgemaster.zombie.org (ip68-13-71-251.om.om.cox.net [68.13.71.251]) by area51.slashnet.org (Postfix) with ESMTP id 6F38A49F33 for ; Wed, 30 Jul 2003 20:23:03 -0400 (EDT) Received: by edgemaster.zombie.org (Postfix, from userid 1001) id ED0EE3983D; Wed, 30 Jul 2003 19:23:04 -0500 (CDT) Date: Wed, 30 Jul 2003 19:23:04 -0500 From: Sean Kelly To: arch@freebsd.org Message-ID: <20030731002304.GA5131@edgemaster.zombie.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: A working watchdog API X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2003 00:23:07 -0000 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/