Hi,
On Mon, 6 Aug 2007, Arjan van de Ven wrote:
> So, let me ask a direct question: What do you think is specifically
> wrong about changing the msleep() implementation as is done here? The
> behavior is clearly an improvement, so what is your objection on the
> flipside?
Again, we have two different timer APIs for a reason - as long as you
ignore this, we won't get much further...
As long as resolution is not an issue, simple timer are generally often
the better choice as they are cheaper. By extension it also makes sense to
offer a sleep based on simple timer.
hrtimer allows for finer resolution, so it makes more sense to offer a
hrtimer based sleep which is not limited to milliseconds, once we have
this sleep, you'll also get the better behaviour you're asking for, which
removes the urgent need having to "fix" msleep.
Contrary to what you think I don't hate hrtimer, they're quite useful, but
they have their use cases as simple timer have. What I want is that people
_think_ before start using them, as in general hrtimer come with a higher
base cost, so one should _think_ before thoughtlessly using them only
because they're the cool new thing. I don't care much about drivers, but
in generic code (which msleep is part of) I'm going to look closer and
I'll continue to ask, whether it really needs to use hrtimer.
In this case I simply see no reason to force hrtimer on msleep, if users
can as well use nanosleep to get the same behaviour.
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]
