Re: kernel/timer.c design (was: Re: ktimers subsystem)

[Roman Zippel]

Hi,

On Wed, 19 Oct 2005, Ingo Molnar wrote:

> > Whether the timer event is delivered or not is completely unimportant, 
> > as at some point the event has to be removed anyway, so that 
> > optimizing a timer for (non)delivery is complete nonsense.
> 
> completely wrong! To explain this, let me first give you an introduction 
> to the design goals and implementation/optimization details of the 
> upstream kernel/timer.c code:

I indeed made a mistake, thanks for pointing it out so elaborately.

I'd like to mention something else here. It's rather bad style to start 
with "completely wrong!" and then continue to gloat with "let me give you 
an introduction", unless you intentionally want to insult me. Usually I 
would just ignore this, as it can happen to anyone, but I can find this 
style too often in your mails lately with the most obvious example of your 
"shut up or show code" comment. You're more busy trying to prove me wrong 
than adressing the actual issue. It never was my intention to discuss the 
kernel timer design (the one in timer.c you describe here), the original 
issue was and still is that "timer API" is a too generic term and you 
actually proved my point by using the terms timer and their timeout values 
very consistently in your description.

It's possible I read this wrong, in that case I apologize already in 
advance, but please rethink the attitude you're showing, otherwise I'll 
reduce our conversion to a minimum. You're certainly have the more 
detailed knowledge in this area, but you don't have to show it off like 
this.

bye, Roman
-
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/