On 23.07.2005 [22:12:30 +0200], Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
>
> > > Jiffies are the basic time unit for kernel timers, hiding that fact gives
> > > users only wrong expectations about them.
> >
> > We already have msleep() and msleep_interruptible(), which hide jiffies
> > in milliseconds. These interfaces are their parallel in the wait-queue
> > case. If you don't want to use them, or their use is not appropriate,
> > then the callers won't be changed.
>
> I'm not exactly impressed with their implementation, it's completely silly
> that there is no such convience function based on jiffies, e.g. if you
> look at the msleep_interruptible(), you'll find quite a few
> "msleep_interruptible(jiffies_to_msecs())".
Patches are welcome, I guess :)
> msleep_interruptible() is especially bad as there are a few users who
> check the return value and since it adds one to the timeout, you can
> create loops which may never timeout (as e.g. in drivers/w1/w1_therm.c:
> w1_therm_read_bin()), this is nice example of a bad interface.
>
> These two function should actually look like this:
>
> static inline void msleep(unsigned int msecs)
> {
> sleep(msecs_to_jiffies(msecs));
> }
>
> static inline int msleep_interruptible(unsigned int msecs)
> {
> sleep_interruptible(msecs_to_jiffies(msecs)) != 0;
> }
Where are sleep() and sleep_interruptible() defined? And this basically
pushes down the identical implementation a layer, correct? Finally, you
cannot simply do msecs_to_jiffies() in the caller of
sleep{,_interruptible()}, unless sleep{,_interruptible()} add 1 to every
request themselves. The basic issue is that with jiffies and ticks being
identical, there is no concept of the inter-tick position (i.e., a
sub-jiffy value), and the callers of these conversion functions *must*
assume they are going to be added to the timer subsystem immediately
before a timer interrupt occurs. An entire tick has not elapsed, but if
the caller had not added 1, then we could potentially go off almost an
entire tick early. The +1 is basically specifying we are asking to add
our delay to the *next* tick.
> > My goal is to distinguish between these cases in sleeping-logic:
> >
> > 1) tick-oriented
> > use schedule_timeout(), add_timer(), etc.
> >
> > 2) time-oriented
> > use schedule_timeout_msecs()
>
> There is _no_ difference, the scheduler is based on ticks. Even if we soon
> have different time sources, the scheduler will continue to measure the
> time in ticks and for a simple reason - portability. Jiffies _are_ simple,
> don't throw that away.
I agree that from an internal perspective there is no difference, but
from an *interface* perspective they are hugely different, simply on the
basis that one uses human-time units and one does not.
I guess we must continue to agree to disagree.
I am still waiting for some feedback from Andrew if he would prefer a
jiffy-only version or both the jiffy and msec version.
Thanks,
Nish
-
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/
