mail archive of the barebox mailing list
 help / color / mirror / Atom feed
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 10:23:58 +0100	[thread overview]
Message-ID: <3c7b27d0-a513-b74f-2a84-2670f74a7e3c@pengutronix.de> (raw)
In-Reply-To: <6e6e03d5-98ea-5872-d00b-5b1d8e5a53ff@klevio.com>



On 18.02.19 09:56, Tomaž Šolc wrote:
> 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.

:) sure

> 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"?

Yes, it is :) at least for a production system. Making some thing bad for development, do 
not justify making a production system in a same bad way.

> 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.

The point of this sentence is to make everybody feel bad if system is designed in a bad way..

Just one example, almost all consumer WiFi router based on Qualcomm Atheros are with 
broken watchdog. It is not avionics, but some times users should just manually reset it 
and it is bad.

bcm2835 with filed SD card, which should be power cycled. Most probably nobody will die if 
it will fail, but it just bad.

In most cases, if you ask: "It is 2019!!! Why this system has no proper watchdog?! why 
should i manually power cycle my router, TV, laptop or PC or even a RPi". The answer will 
be: "Well, it is not so important, ... we do not even feel bad about it"

If some thing is bad, it should be called as bad. No political correctness.. I hope you 
understand my point ;D

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

  reply	other threads:[~2019-02-18  9:24 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
2019-02-18  9:23       ` Oleksij Rempel [this message]
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=3c7b27d0-a513-b74f-2a84-2670f74a7e3c@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