Hi,
On Sat, 4 Aug 2007, Arjan van de Ven wrote:
> > hr_msleep makes no sense. Why should we tie this interface to millisecond
> > resolution?
>
> because a lot of parts of the kernel think and work in milliseconds,
> it's logical and USEFUL to at least provide an interface that works on
> milliseconds.
If the millisecond resolution is enough for these users, that means the
current msleep will work fine for them.
> > Your suggested msleep_approx makes not much sense to me either, since
> > neither interface guarantees anything and may "approximate" the sleep
> > (and if the user is surprised by that something else already went wrong).
>
> an interface should try to map to the implementation that provides the
> best implementation quality of the requested thing in general. That's
> the hrtimers based msleep().
This generalization is simply not true. First it requires the
HIGH_RES_TIMERS option to be enabled to really make a real difference.
Second a hrtimers based msleep has a higher setup cost, which can't be
completely ignored. "Best" is a subjective term here and can't be that
easily generalized to all current users.
> > If you don't like the hrsleep name, we can also call it nanosleep and so
> > match what we already do for userspace.
>
> having a nanosleep *in addition* to msleep (or maybe nsleep() and
> usleep() to have consistent naming) sounds reasonable to me.
We only need one sleep implementation of both and msleep is a fine name
for the current implementation - not only does it describe the unit, but
it also describe the best resolution one can expect from it.
> Do you have something against hrtimer use in general? From your emails
> on this msleep topic it sort of seems you do....
I can give the question back, what do you have against simple timers, that
you want to make them as awkward as possible to use?
hrtimer have a higher usage cost depending on the clock source, so simply
using them only because they are the new cool kid in town doesn't make
sense. It may not be that critical for a simple sleep implementation, but
that only means we should keep the API as simple as possible, that means
one low resolution, cheap msleep and one high resolution nanosleep is
enough. Why do you insist on making more complex than necessary?
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]
