On 2/17/22 19:17, Guenter Roeck wrote: > On 2/17/22 09:49, Gabriele Paoloni wrote: >> >> >> On 17/02/2022 18:27, Guenter Roeck wrote: >>> On 2/17/22 08:27, Daniel Bristot de Oliveira wrote: >>>> Hi Peter >>>> >>>> On 2/16/22 17:01, Peter.Enderborg@xxxxxxxx wrote: >>>>> On 2/14/22 11:45, Daniel Bristot de Oliveira wrote: >>>>>> Add a set of tracepoints, enabling the observability of the watchdog >>>>>> device interactions with user-space. >>>>>> >>>>>> The events are: >>>>>> watchdog:watchdog_open >>>>>> watchdog:watchdog_close >>>>>> watchdog:watchdog_start >>>>>> watchdog:watchdog_stop >>>>>> watchdog:watchdog_set_timeout >>>>>> watchdog:watchdog_ping >>>>>> watchdog:watchdog_nowayout >>>>>> watchdog:watchdog_set_keep_alive >>>>>> watchdog:watchdog_keep_alive >>>>> >>>>> Some watchdogs have a bark functionality, I think it should be event >>>>> for that too. >>>>> >>>> >>>> I understand. The problems is that I do not see the bark abstraction >>>> in the >>>> watchdog_dev layer. >>>> >>> >>> I don't even know what "bark functionality" means. A new term for >>> pretimeout ? >>> Something else ? >> >>> From my understanding the bark timeout is actually the pretimeout >> whereas the bite timeout is the actual timeout. >> I think in the Kernel ftwdt010_wdt and qcom-wdt are bark/bite WTDs >> > > If that is the case, I would prefer if we could stick to existing > terminology to avoid issues like "I do not see the bark abstraction". I agree! I am using the terminology from watchdog dev. Like, I hear the term "pet" for the "ping", I used "ping." -- Daniel
