Re: [patch 00/43] ktimer reworked

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

On Wed, 30 Nov 2005, Kyle Moffett wrote:

> If I recall correctly, this whole naming mess has been discussed to death
> before, with the result that almost everybody but Roman thought the names were
> perfectly clear such that a timer is _expected_ to expire and a timeout is
> not, therefore timers should be optimized for add=>run=>expire and timeouts
> optimized for add=>run=>remove.

The human language is a bit more complicated than this (at least English 
and related languages). Depending on the context a word can have different 
meanings, e.g. if you ask an athlete what "timeout" means, you'll get a 
different answer than you would get from an engineer. Even if we limit it 
to the technical field one can define "timeout" very generally as "a 
period of time after which an event is generated". Does this imply this 
timeout is usually aborted? For some people it obviously does, but I 
highly doubt this is generally true. Without any context "timeout" can 
mean many similiar, but still different things. If you don't provide any 
context, it will trigger different associations and people will add their 
own context of how they use "timeout". You will of course find a large 
overlap, but the less context you provide, the more likely are 
misunderstandings.

A good name provides enough context to minimize misunderstandings, the 
name is important for how people will perceive and use something. Here we 
get to a larger problem, which goes beyond simple naming issues. Thomas 
and Ingo seem to want to completely redefine how time is managed in the 
kernel. The consequences for this would be very farreaching and should be 
discussed independently. Discussing this under the topic of high 
resolution timer would provide the entirely wrong context and lead to 
misunderstandings.

Whatever it is Thomas and Ingo are trying to do with the current kernel 
timer, they have to explain it in the proper context. I'm not going to 
second-guess their intentions and sneaking these changes in as part of the 
high resolution timer is unacceptable.

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