ipmi watchdog questions

[Don Zickus <dzickus@redhat.com>]

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?

- Is there a reason why the ipmi_watchdog is a seperate module as opposed
  to being called by ipmi_si?  It seems there shouldn't be an issue with
the watchdog always loaded, it just won't do anything until someone opens
it (from my understanding).  Also you would gain the ability to use the
shutdown/remove routines properly instead of the reboot/panic notifiers.

  In addition, passing the pointer to the 'struct watchdog_device' would be
easier if some of those extra pieces were not there (as opposed to making
it a global reference).

- What does the fasync and poll calls do for a watchdog?

I'll start with that for now.

I appreciate any feedback.  Currently we just implemented blacklisting the
iTCO watchdog driver to workaround this problem.  I thought we could do
better, hence my motivation to do work in this area.

Cheers,
Don