2018-03-04 22:19 GMT+03:00 Pavel Machek <pavel@xxxxxx>: > Improving WDIOC_SETTIMEOUT is obvious solution. I'd go for that. Question is, then, - how to do it in a backwards-compatible manner? There is very likely to be some userspace software out there which relies on the assumption of the currently used whole seconds semantics being in effect. Add a new millisecond argument? But how to detect its presence in the handler? Introduce a new ioctl? But how to do it neatly and reasonably? > But actually, controlling GPIO entirely from userspace should work > well, too. User is not going to notice the jitter in miliseconds... >From my experience, sometimes a heavy load on the CPU by other processes may cause quite noticeable lags, and it's hard to make sure that our other developers would nice up their processes to give the LED blinker enough 'priority'. Also, that doesn't factor in the time between the boot and the process startup, since in our configuration the 'system' processes such as watchdog are run way earlier than the 'appliance' processes, however the former may be in a read-only squashfs partition which is a pain to update. But I'd like to have it up and running as soon as possible, so...
