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/
next prev parent 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.