On Wed, Aug 08, 2012 at 10:22:18PM +0200, Wim Van Sebroeck wrote: > > That being said, we could do so if ENOIOCTLCMD worked as you suggest, but > > it doesn't quite. Drivers with an ioctl op will return ENOTTY, in which > > case the switch statement would work, but drivers with no ioctl op (e.g. > > softdog) cause watchdog_ioctl_op to return ENOIOCTLCMD, causing the switch > > statement to be skipped. > > at this moment all drivers that are allready converted to the general watchdog > infrastructure/API don't need and thus don't have an ioctl operation in place. > They all use the common code. Before we added the WDIOC_GETTIMELEFT to the > framework, I had the converted iTCO_wdt driver using an ioctl operations call > that used the ENOIOCTLCMD without any issue. Yeah, that's what confused me. I mistakenly thought the ioctl methods I saw in the drivers were called by watchdog_dev, when in fact they are just unconverted. There's no point in adding the new ioctl to unconverted drivers. > I'm going to be honoust: I don't understand the use case. I have the impression > that you want to solve High Availability issues with watchdog resets... Yes. I'm using the watchdog as an alternative to i/o fencing in a shared storage cluster. > And that's like replacing a car with a new car when you are out of gasoline... I guess you mean that reseting a machine sounds severe. It's not if you consider the context of i/o fencing where you often use a power switch to turn off a machine to fence it. > So, I need to think more about this and I wonder if other people have the same > issue as you have with the extra ping. People who *want* the watchdog to fire given certain conditions and also want the most predictability about it, would probably appreciate no ping generated by the kernel in close, but only generated themselves by ioctl. There are a couple ways I can work around this at the moment, but neither is very nice. First, I can add an extra 60 seconds to my timeout calculations in order to account for a ping that the kernel generates if my daemon is killed just before the watchdog was about to fire. Second, the approach I'm using now, is to pre-emptively close the device specifically to use the close to generate what might be the final ping that I actually want. I then re-open the device if it turns out that it wasn't in fact the final one I needed. So, I use close and re-open to issue some of the keepalives instead of ioctl. This adds complexity. (In the pathological case, you end up doing repeated open&close of the device to generate all your pings, instead of ioctl!) > The code for the complete system would be translated as a module or kernel parameter > and not as an extra ioctl. > If it would be needed for specific drivers then we need a more generic approach > that will also let us tweak other items in the future so that we don't need an ioctl > for every change of behaviour. I would need it in the general case, for the complete system. But, I would also need to be able to detect if the behavior was enabled or not on a given system. Thanks, Dave -- 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
