On 05/01/2014 08:11 PM, Guenter Roeck wrote: > On 05/01/2014 05:38 PM, Corey Minyard wrote: >> On 05/01/2014 08:58 AM, Don Zickus wrote: >>> Hi Corey, >>> >>> I stumbled upon an issue with a partner of ours, where they booted >>> their >>> machine and tried to load the ipmi_watchdog module by hand and it >>> failed. >>> >>> The reason it failed was that the iTCO watchdog driver was already >>> loaded >>> and it registered the misc device /dev/watchdog first. >>> >>> I looked at the ipmi watchdog driver and realized it was never >>> converted >>> to the new watchdog framework where the watchdog_core module manages >>> the >>> '/dev/watchdog' misc device. >>> >>> So being naive and not knowing much about IPMI, I decided to follow the >>> helpful document >>> Documentation/watchdog/convert_drivers_to_kernel_api.txt >>> and convert the ipmi_watchdog to use the new watchdog framework. >>> >>> I ran into a few issues and then realized the driver itself never >>> really >>> binds to any hardware, so it makes the conversion process a little more >>> challenging. >>> >>> So a few questions to you before I waste my time in this area: >>> >>> - Is there any prior history about why the ipmi_watchdog was never >>> converted to the new watchdog framework? Lack of interest? >>> Technical >>> hurdles? >> >> Mostly lack of interest, but there are some technical hurdles. >> >> It would be hard to implement some things. The watchdog framework has >> no concept of pretimeouts. And IPMI is message based, you send a > > Are you saying that WDIOC_SETPRETIMEOUT and WDIOC_GETPRETIMEOUT don't > work > for ipmi ? If so, can you explain ? > That isn't enough to be able to report the pretimeout to the user. You can set it and get it with those calls, but it also needs poll, fasync, and read to be able to select on a pretimeout or block on a read. >> message to a controller to do anything, and you have to wait for the >> response. That doesn't work very well with the watchdog interface, >> which assumes you can do everything immediately. >> > Does it ? How so ? Please elaborate; I don't immediately see how the > watchdog > subsystem would prevent you from using, say, kernel threads or delayed > workers > to implement asynchronous access to or from any underlying hardware. > I was remembering you couldn't block in the various calls, but looking at the code, I see that's not an issue. -corey -- 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
