[lkml]   [1999]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: jiffies and co

On Tue, 17 Aug 1999, David Weinehall wrote:

> On Mon, 16 Aug 1999, Linus Torvalds wrote:
> >
> >
> > On Mon, 16 Aug 1999, Gerard Roudier wrote:
> > >
> > > Why is jiffies type still 'unsigned long', given that all calculations
> > > that try to be not too wrong with wrap-around just cast timer values to
> > > signed long?
> >
> > Why not?
> >
> > You shouldn't really do compares on it anyway, so the type doesn't matter.
> > And to me, "unsigned" makes much more sense for time as it is implemented
> > in the kernel - it never goes negative, but it can wrap. That's basically
> > what "unsigned" means.
> >
> > Also the C standard actually guarantees nice wrapping behaviour for
> > unsigned, something it doesn't guarantee for signed values. So as long as
> > you're working with wrapping values, you should always use unsigned. We
> > then at the last possible moment know that we're playing with a two's
> > complement machine, and that's where we do the signed cast to test the
> > high bit to make it easy on the compiler, but you could conceptually think
> > of it as a test for the high bit (which is portable C) rather than as a
> > test for the sign (which is _not_ portable C, but nobody cares because
> > nobody sane does anything but two's complement).
> >
> > So I really don't see the point of trying to change the type to anything
> > else or trying to hide it with some random new typedef that doesn't buy
> > you anything in real life. Don't abstract things away unless you get some
> > real _advantage_ from the abstraction, and I don't see the advantage.
> >
> > Linus
> >From just a quick scan (grep + ocular-investigation), there seem to be at
> least a few places left in the kernel where jiffies are treated as int,
> not unsigned long. Are those left on purpose, or should I fix 'em up?!

Do you mean that you inspected the whole 2419 lines of code that refers to
jiffies and investigated the corresponding source files ? ;-)
I would be impressed if I really beleived so. :)

All this mess-up for, in fact, a simple problem. But as we know, dealing
with date and time hasn't been a great success in I.T. The Y2K problem
will be our punishment.

In most cases where you need to deal with timeout, you just have to:

1) Calculate a deadline by adding some positive delta to the current

2) Test for the expiration of this deadline.

You can cover this need by 2 simple abstractions in Linux:

1) Calculate the kernel time of the deadline:
#define ktime_get(delta) (jiffies + (u_long)(delta))

2) Check against the expiration:
#define ktime_exp(tlimit) ((long)jiffies - (long)(limit)) >= 0)
(assuming that tlimit has been obtained using ktime_get())

I bet everybody that the above trivial stuff covers more than 80% of
the needs regarding timeout issues.

For more complex stuff or guys, we can add some other stuff and advise
users to use it only when it is really needed, for example:

3) Add a delta to a kernel time value:
#define ktime_add(a, d) ((a) + (u_long)(d))

4) Substract a delta from a kernel time value:
#define ktime_sub(a, d) ((a) - (u_long)(d))

5) Compare or diff 2 kernel time values:
#define ktime_dif(a, b) ((long)(a) - (long)(b))

It seems that time issue is too complex for the average human. Einstein
have had to suffer of that in some early time and we all will suffer of
the Y2K catastroph due to this human abstraction limitation. ;-)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:53    [W:0.047 / U:3.088 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site