From: Oleksij Rempel <o.rempel@pengutronix.de>
To: "Tomaž Šolc" <tomaz.solc@klevio.com>, barebox@lists.infradead.org
Subject: Re: [PATCH v3] Documentation: add watchdog documentation
Date: Mon, 18 Feb 2019 09:06:16 +0100 [thread overview]
Message-ID: <5a89d7ae-1416-e900-daf2-06c851281334@pengutronix.de> (raw)
In-Reply-To: <d71ee75b-55e0-fd12-bbdf-647fd7fa57c1@klevio.com>
On 18.02.19 08:56, Tomaž Šolc wrote:
> On 18. 02. 19 08:12, Oleksij Rempel wrote:
>> +A watchdog is the last line of defense on misbehaving systems. Thus, proper
>> +hardware and watchdog design considerations should be made to be able to reduce
>> +the impact of failing systems in the field. In the best case, the bootloader
>> +should not touch it at all. No watchdog feeding should be done until
>> +application-critical software (or a userspace service manager such as
>> +'systemd') was started.
>> +
>> +In case the bootloader is responsible for watchdog activation, the system can
>> +be considered as failed by design.
>
> I think this is too strongly worded and I would leave out this last sentence. It seems
> arrogant for documentation to judge what is "failed by design" like this, without
> considering any other requirements for a system.
Can you please provide an example of a requirement, which can't be considered as bad design.
> Such a "failed" watchdog is still better than no watchdog in many cases and sometimes it's
> the only option, as the text in later paragraphs explains. The paragraph above already
> recommends that in the ideal case the bootloader shouldn't touch the watchdog. I think
> that is enough.
>
> Also, as far as I know, the Linux kernel will feed the watchdog on a kernel timer during
> boot and until a userspace process grabs /dev/watchdog. So based on this basically all
> systems based on Linux are already a failed design.
Correct. The fact, it is enabled by default in kernel do not means, it was a good decision.
Kind regards,
Oleksij Rempel
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2019-02-18 8:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-18 7:12 Oleksij Rempel
2019-02-18 7:56 ` Tomaž Šolc
2019-02-18 8:06 ` Oleksij Rempel [this message]
2019-02-18 8:56 ` Tomaž Šolc
2019-02-18 9:23 ` Oleksij Rempel
2019-09-24 7:54 Oleksij Rempel
2019-09-25 10:09 ` Sascha Hauer
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=5a89d7ae-1416-e900-daf2-06c851281334@pengutronix.de \
--to=o.rempel@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=tomaz.solc@klevio.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox