Re: Very imprecise watchdogd(8) timeout

Hi,

On Fri, Sep 16, 2011 at 4:03 PM, Poul-Henning Kamp <phk_at_phk.freebsd.dk> wrote:
> In message <CACqU3MWs0HHnZchOwmwWG8U9Vd2pBDKAqf6Pdw5zS_XO_S6Ppw_at_mail.gmail.com>
> , Arnaud Lacombe writes:
>
>>I just had a look to the way the timeout specified to watchdogd is
>>passed to the kernel. watchdogd(8) says:
>
> The API was designed for simplicity, not precision.
>
> Watchdog hardware often have weird and strange limitations on the
> actual values you can set.
>
yes.

> A very typical, the most typical in my experience, is "some
> frequency, a binary prescaler, possibly with a counter.
>
> It is also not uncommon to have more than one watchdog
> mechanism in the same system.
>
in which case the current notifier-based architecture is broken. You
may want to have a soft-watchdog triggering after 5s, and a fallback
hardware watchdog triggering after 60s.

> It would be overkill to design and implement a complex API to
> communicate these limitations to userland.
>
Linux is going this way, at least for a min/max seconds timeount info,
did not check the rest.

> So the API was designed around the power-of-two scale to give it
> a wide range, and with the semantics "no shorter than", to make
> it easy to use, and for multiple watchdogs to be engaged to the
> best of their ability.
>
wide range ? 50% of the possibility are unusable (every value below
29) and the rest is limited by what the device support anyway. Take
the geodewdt, a max timeout of 2h26, so with the actual sparse range,
you will only be able to set timeout to 1s, 2s, 4s, 8s, 17s, 34s, 68s,
274s, 549s, 1099s, 2199s, 4398s. That's 20% of the original range...

> If this is not precise enough for you, come up with something
> better.
>
I do not really care actually, but the manpage is wrong, and the code
needlessly complicated. You can just rip all the
double-to-int-log-of-nanosecond-timeout mambo-jumbo, and advertise in
watchdogd(8) that only power of two timeout are supported, or have an
option to directly specify the shift, that'll be simpler and correct.

 - Arnaud