[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5B8DA87D05A7694D9FA63FD143655C1B540EEC58@hasmsx108.ger.corp.intel.com>
Date: Sun, 20 Dec 2015 12:53:07 +0000
From: "Winkler, Tomas" <tomas.winkler@...el.com>
To: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Guenter Roeck <linux@...ck-us.net>
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Wim Van Sebroeck <wim@...ana.be>,
"Usyskin, Alexander" <alexander.usyskin@...el.com>,
"linux-watchdog@...r.kernel.org" <linux-watchdog@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [char-misc-next v2 7/7] watchdog: mei_wdt: re-register device
on event
>
> > > That breaks the existing behaviour of hot pluggable watchdog interfaces
> > > and is different to just about any other device in the kernel. Today with
> > > any desktop or server distribution you can already trivially arrange for
> > > watchdog daemons to start at the point a watchdog is detected dynamically.
> > >
> >
> > Ok, you have a point. Wonder if any distributions are doing that, though.
> > Any idea ?
>
> I don't know for any of the out of the box mainstream ones.
>
> There is a second problem if you register the watchdog but don't actually
> have it enabled. Consider the case where a user has the mei watchdog
> disabled and a more advanced watchdog card plugged in - in that case the
> naïvely implemented existing watchdog app may bind to the non-functional
> watchdog, not the correct one.
That's correct, though WDIOF_ALARMONLY or device identity has to be checked.
And if mei is disabled one would probably hit ENODEV, still there will be no uevent to the user space
when the device is provisioned again, so still I prefer add/removing the watchdog device.
Thanks
Tomas
Powered by blists - more mailing lists