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/