From: "Tomaž Šolc" <tomaz.solc@klevio.com>
To: Oleksij Rempel <o.rempel@pengutronix.de>, barebox@lists.infradead.org
Subject: Re: [PATCH v3] Documentation: add watchdog documentation
Date: Mon, 18 Feb 2019 09:56:57 +0100 [thread overview]
Message-ID: <6e6e03d5-98ea-5872-d00b-5b1d8e5a53ff@klevio.com> (raw)
In-Reply-To: <5a89d7ae-1416-e900-daf2-06c851281334@pengutronix.de>
On 18. 02. 19 09:06, Oleksij Rempel wrote:
> On 18.02.19 08:56, Tomaž Šolc wrote:
>> On 18. 02. 19 08:12, Oleksij Rempel wrote:
>>> +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.
Not everything is an avionics system that needs to address cosmic
particles or whatever. That doesn't make it a bad design and it's not
realistic to expect everything to be made up to such standards.
Documentation calling 90% of systems out there "failed by design" is
just driving potential users away in my opinion. It's ok to make people
aware of the limitations though (and I think the rest of your text does
that just fine).
You list an example yourself below in the text: things like netboot can
make boot time unpredictable enough that watchdog must be feed during
boot. Are all netboot systems "failed by design"?
Some systems don't allow the watchdog to be enabled permanently, but
need software to enable it (example: bcm2835). Bootloader is the
earliest point where this can be done. This solves a bad kernel update
(might be a requirement for a consumer device), but doesn't address
power supply glitches during bootloader operation (might not be a
requirement).
Anyway, just an opinion from someone new to Barebox.
Best regards
Tomaž
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2019-02-18 8:57 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
2019-02-18 8:56 ` Tomaž Šolc [this message]
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=6e6e03d5-98ea-5872-d00b-5b1d8e5a53ff@klevio.com \
--to=tomaz.solc@klevio.com \
--cc=barebox@lists.infradead.org \
--cc=o.rempel@pengutronix.de \
/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