All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Lynch <rusty@linux.co.intel.com>
To: Daniel Pittman <daniel@rimspace.net>
Cc: wingel@nano-systems.com, lkml <linux-kernel@vger.kernel.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH][RFC] Proposal for a new watchdog interface using sysfs
Date: 12 Feb 2003 23:32:38 -0800	[thread overview]
Message-ID: <1045121561.2326.27.camel@vmhack> (raw)
In-Reply-To: <87n0l0olel.fsf@enki.rimspace.net>

On Wed, 2003-02-12 at 20:27, Daniel Pittman wrote:
> On 12 Feb 2003, Rusty Lynch wrote:
> > The following is a proposal for a new sysfs based watchdog interface
> > to be used as a replacement for the current char device w/ ioctl api
> > as described in Documentation/watchdog-api.txt.
> 
> [...]
> 
> > Where each these files to the following ==>
> > 
> > start (RO)
> >   - show: starts watchdog count
> 
> This would be much better as a store -- that way 'cat /.../watchdog0/*'
> will not activate the watchdog. A more deliberate action is safer for
> forgetful admins, such as me.
> 

Sounds logical.  My reasoning was more of a coin toss.

> [...]
> 
> > status (RO)
> >   - show: prints the current status value
> > 
> > bootstatus (RO)
> >   - show: same as 'status', but valid for just after the last reboot.
> 
> [...]
> 
> > enable (RW)
> >   - show: prints 0 or 1 to indicate if the wdt is enabled
> >   - store: expects 0 or 1 to disable or enable the wdt
> 
> Isn't this the same information as the 'status' and 'start' members?
> 
>       Daniel

Now that think about it, enable really is the same as start/stop, but
the status is still something different.  I didn't really talk about it,
but my intent was to provide the information currently available from
the WDIOC_GETSTATUS ioctl, which is a value composed of the following
flags:

#define	WDIOF_OVERHEAT		0x0001	/* Reset due to CPU overheat */
#define	WDIOF_FANFAULT		0x0002	/* Fan failed */
#define	WDIOF_EXTERN1		0x0004	/* External relay 1 */
#define	WDIOF_EXTERN2		0x0008	/* External relay 2 */
#define	WDIOF_POWERUNDER	0x0010	/* Power bad/power fault */
#define	WDIOF_CARDRESET		0x0020	/* Card previously reset the CPU */
#define WDIOF_POWEROVER		0x0040	/* Power over voltage */
#define WDIOF_SETTIMEOUT	0x0080  /* Set timeout (in seconds) */
#define WDIOF_MAGICCLOSE	0x0100	/* Supports magic close char */
#define	WDIOF_KEEPALIVEPING	0x8000	/* Keep alive ping reply */

I debated with myself if each of these flags should be broke out into
their own file, and I'm still not sure if it is better to keep the
status as a single file.

> 
> -- 
> A cathedral, a wave of a storm, a dancer's leap,
> never turn out to be as high as we had hoped.
>         -- Marcel Proust
> -
> 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/



  reply	other threads:[~2003-02-13  7:23 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-13  3:16 [PATCH][RFC] Proposal for a new watchdog interface using sysfs Rusty Lynch
2003-02-13  4:27 ` Daniel Pittman
2003-02-13  7:32   ` Rusty Lynch [this message]
2003-02-13 11:55 ` Dave Jones
2003-02-13 15:34   ` Rusty Lynch
2003-02-13 16:04     ` Patrick Mochel
2003-02-13 15:51       ` Rusty Lynch
2003-02-13 19:07         ` Dave Jones
2003-02-13 18:31           ` Rusty Lynch
2003-02-13 19:19             ` Patrick Mochel
2003-02-13 21:12               ` Scott Murray
2003-02-13 22:58                 ` Matt Porter
2003-02-13 22:05                   ` Rusty Lynch
2003-02-14  0:47                     ` Rusty Lynch
2003-02-14 14:48                       ` Alan Cox
2003-02-14 15:32                         ` Rusty Lynch
2003-02-14 17:55                           ` Alan Cox
2003-02-14 19:02                             ` Rusty Lynch
2003-02-14 20:43                               ` Alan Cox
2003-02-14 21:12                             ` Joel Becker
2003-02-14 13:48                   ` Valdis.Kletnieks
2003-02-14 14:57                     ` Alan Cox
2003-02-13 16:04     ` Dave Jones
2003-02-13 18:20 ` Rusty Lynch
2003-02-13 18:21 ` Rusty Lynch
2003-02-13 23:04   ` Pavel Machek
2003-02-14 22:12     ` Alan Cox
2003-02-14 21:35       ` Pavel Machek
2003-02-14 23:17         ` Rusty Lynch
2003-02-15  1:54           ` Alan Cox
2003-02-15  8:27             ` Cort Dougan
2003-02-15  9:13               ` John Bradford
2003-02-15 21:03                 ` Alan Cox
2003-02-15 20:37                   ` John Bradford
2003-02-15 12:42               ` Ingo Oeser
2003-02-15 17:26               ` Pavel Machek
2003-02-19  5:24             ` Rusty Lynch
2003-02-20 21:19               ` Jakob Oestergaard
2003-02-20 22:36                 ` Alan Cox

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=1045121561.2326.27.camel@vmhack \
    --to=rusty@linux.co.intel.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=daniel@rimspace.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wingel@nano-systems.com \
    /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.