All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Jean Delvare <jdelvare@suse.de>
Cc: Wim Van Sebroeck <wim@iguana.be>,
	linux-watchdog <linux-watchdog@vger.kernel.org>
Subject: Re: Watchdog drivers and device driver model
Date: Fri, 7 Mar 2014 09:29:39 -0800	[thread overview]
Message-ID: <20140307172939.GA32353@roeck-us.net> (raw)
In-Reply-To: <1394206246.4376.53.camel@chaos.site>

Hi Jean,

On Fri, Mar 07, 2014 at 04:30:46PM +0100, Jean Delvare wrote:
> Hi Guenter,
> 
> Le Friday 07 March 2014 à 06:37 -0800, Guenter Roeck a écrit :
> > On 03/07/2014 05:34 AM, Jean Delvare wrote:
> > > If you need some background: my customer needs to unload the native
> > > watchdog driver and use the IPMI watchdog instead. So they need a
> > > reliable way to figure out who is handling /dev/watchdog so that they
> > > can unload the right module. This is rather difficult, costly and
> > > fragile with the way things are currently implemented.
> >
> > Another solution in that specific case would be to convert the ipmi
> > watchdog driver to the watchdog API. Then it could be loaded in parallel
> > with other watchdog drivers. Of course, the naming problem would still
> > exist.
> 
> Not sure if it would help. If both the native watchdog driver and the
> IPMI watchdog driver get loaded automatically via module aliases, it
> will be racy. Only one driver can own /dev/watchdog at any given time,
> and the use has to decide which one.
> 
At work we are using /dev/watchdog0 and /dev/watchdog1 directly,
and don't depend on /dev/watchdog (which maps to /dev/watchdog0).
This is actually quite convenient, as it lets us use the two watchdogs
to watch each other (I've seen hard system lockups with the mei
watchdog and the iTCO watchdog on a couple of systems, so I like to
have a backup).

Sure, if you insist that the ipmi watchdog is tied to /dev/watchdog,
no matter what, that is a different issue.

Anyway, in our case it doesn't matter much which watchdog is on
which device, because we just use both. But I agree that it would
be nice to have an easy way to determine the underlying device
from user space (without having to go through the ioctl to get
the name).

Guenter

  reply	other threads:[~2014-03-07 17:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-07 13:34 Watchdog drivers and device driver model Jean Delvare
2014-03-07 14:37 ` Guenter Roeck
2014-03-07 15:30   ` Jean Delvare
2014-03-07 17:29     ` Guenter Roeck [this message]
2014-03-08 12:27       ` Jean Delvare
2014-03-08 14:12         ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140307172939.GA32353@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=jdelvare@suse.de \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=wim@iguana.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.