lkml.org 
[lkml]   [2005]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-10-17 22:15    [W:0.198 / U:0.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site