Re: [patch 00/43] ktimer reworked

[Andrew Morton]

Ingo Molnar <mingo@xxxxxxx> wrote:
>
> we could merge the two by driving 'timeouts' via ktimers too - but there 
>  would be some unavoidable overhead to things like the TCP stack. But 
>  ktimers cannot be merged into timeouts, that's sure.

I think you guys have an advantage over me because you've been discussing
and thinking about this terminology for months.  IOW, your lips are moving
but all I hear is blah, blah, blah ;) 

For instance, when Kyle came out with his one-sentence description of
timers versus timeouts, I thought he had them backwards.  Only apparently
he didn't.

So either it's all confusing, or I'm dumb, or both.  I can evade
investigation of that by claiming that we should seek something which is
unconfusing to even dumb people.

We have timer_lists.  But you say they don't suit precision timers.  Fine. 
So why cannot we call the new precision timers something like "precision
timers" and avoid this semantic confusion over timeouts versus timers?

IOW: leave timer_lists alone.  Just add the needed new subsystem and use it.

I guess old-timers can mentally do s/ktimeout/timer_list/ whenever they
come across the danged thing, but it's a bit painful.  If we called them
"timer_list" and "hrtimer", things would be much clearer.  Plus that's a
description of what they *are*, rather than of how we expect them to be
applied.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/