Messages in this thread | | | Date | Mon, 17 Oct 2005 22:13:30 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5 |
| |
* Roman Zippel <zippel@linux-m68k.org> wrote:
> > Maybe for a more experienced kernel person such as > > yourself, this distinction make sense. But > > "process timer" and "kernel timer" don't carry much > > semantic value for me. They seem to convey an > > arbitrary expectation of usage patterns. Maybe > > they match the current usage patterns in the kernel, > > but I'd prefer naming based on functionality or > > behaviour of the API. > > Let's say you want to implement a watchdog timer for a driver, which > runs about every second to do something. Now if you have the choice > between "timer API" vs. "timeout API" and "kernel timer" vs. "process > timer", what would you choose based on the name?
why you insist on ktimers being 'process timers'? They are totally separate entities, not limited to any process notion. One of their first practical use happens to be POSIX process timers (both itimers and ptimers) via them, but no way are ktimers only 'process timers'. They are very generic timers, usable for any kernel purpose.
so to answer your question: it is totally possible for a watchdog mechanism to use ktimers. In fact it would be desirable from a robustness POV too: e.g. we dont want a watchdog from being overload-able via too many timeouts in the timer wheel ...
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |