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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
