lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 11 Dec 2009 16:33:23 +0800
From:	Cypher Wu <cypher.w@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Questions about Watch Dog Timer under Linux.

I'm not sure if there is already a framework to cope with this
situation, or I've design it myself to use kernel thread to work with
the real WDT and interface to the user space application? And since
the WDT start to work just a very short interval after the system
power on, do I have to modify mboot  and Linux kernel to support dog
clearing from the very beginning?


On Thu, Dec 10, 2009 at 12:29 AM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> products is usually a seperate chip on the board wich will start to
>> work after power reset and will time out in 2 seconds. The system has
>> to start dog clearing from the very beginning and there have no way to
>> disable WDT.
>
> That will be fun as you will probably need to start some kind of kernel
> task refereshing it early in boot unless your boot is very quick.
>
> If it cannot be disabled then you don't need to support the disable
> option. The watchdog API is a range of features designed to cover all
> watchdogs. Many only have a few of the features. A large number of the
> supported watchdogs only support a single timeout rate.
>
>> Is this the pattern we have to follow to use WDT under Linux? We have
>> to choose a chip as WDT, and it seems the chip we've familiar under
>> embedded systems can't be used under Linux?
>
> There are two ways to handle this depending on your needs and what the
> applications require. The first is to provide the real hardware interface
> - 2 second fixed timeout, no disable. That's perfectly sufficient.
>
> The other (which some devices do) is to create a kernel thread that
> refreshes the watchdog each second but *only* if a user application has
> made a watchdog call within the last [whatever] seconds. That also allows
> you to provide a disableable watchdog. More flexible but extra work and
> if your embedded system doesn't need the extra facilities - why bother 8)
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ