From: Arnd Bergmann <arnd@arndb.de>
To: Nathan Lynch <ntl@pobox.com>
Subject: Re: [PATCH 3/8] ppc64: add a watchdog driver for rtas
Date: Wed, 18 May 2005 09:14:41 +0200
User-Agent: KMail/1.7.2
Cc: linuxppc64-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>,
       linux-kernel@vger.kernel.org, Anton Blanchard <anton@samba.org>,
       Utz Bacher <utz.bacher@de.ibm.com>, Wim Van Sebroeck <wim@iguana.be>
References: <200505132117.37461.arnd@arndb.de> <200505132124.48963.arnd@arndb.de> <20050517204029.GA2748@otto>
In-Reply-To: <20050517204029.GA2748@otto>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200505180914.44336.arnd@arndb.de>
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1370
Lines: 42

On Dinsdag 17 Mai 2005 22:40, Nathan Lynch wrote:
> Arnd Bergmann wrote:
> > +static volatile int wdrtas_miscdev_open = 0;
> ...
> > +static int
> > +wdrtas_open(struct inode *inode, struct file *file)
> > +{
> > +	/* only open once */
> > +	if (xchg(&wdrtas_miscdev_open,1))
> > +		return -EBUSY;
> 
> The volatile and xchg strike me as an obscure method for ensuring only
> one process at a time can open this file.  Any reason a semaphore
> couldn't be used?

A semaphore would also be the wrong approach since we don't want
processes to block but instead to fail opening the watchdog twice.
Other watchdog drivers use atomic_t or bitops to guard open, which
imho would be the better solution.

Of course, there is also Wim's plan to do a unified watchdog driver
that would solve this once and for all. 

> > +		printk("wdrtas: got unexpected close. Watchdog "
> > +		       "not stopped.\n");
> 
> printk's need a valid log level specified.  There are several in this
> file that lack them.

Right.

Utz, do you have time to fix up these issues? If not, I probably won't
look into it this week either.

Thanks,

	Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/