lkml.org 
[lkml]   [1998]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: typo in scsi_obsolete.c

On Sun, 29 Nov 1998, MOLNAR Ingo wrote:

> On Sun, 29 Nov 1998, Gerard Roudier wrote:
>
> > The formula time_after(jiffies, least_reset + MIN_RESET_PERIOD) looks
> > like very poor semantic to me. I donnot even want to ever burn a
> > single neuron to understand it.
>
> time_before(x,y) means: 'is x before y?'.
> time_after(x,y) means: 'is x after y?'.

The neuron that allows me to understand this is still alive. :-)
Anyway the above makes no sense with counters that wrap around, unless you
assume that the distance between x and y must be smaller than some value
less or equal to half the range of the unsigned integer type used for
'time values', and:
time_after(x, y) defined as ((long)(y) - (long)(x) < 0)
does the trick.

The thing that seems very ugly to me is adding/substracting explicitely
integer values from a kernel time stamp. It was so easy to make it opaque
in order to be able to do some changes without having to change lots of
things in kernel sources if some better idea will be discovered later.

> where both values are 'time' represented as signed integers.
>
> > I may want to understand something that looks like the following:
> > is_in_the_future(u_long time_stamp_in_the_past, u_long delay)
>
> you can always add integers to time. The only thing that has to be wrapped
> is comparison. Thus:
>
> x+d means: 'd units after x'
> x-d means: 'd units before x'
>
> the whole concept is that we are representing a 'time ring' via signed
> integers, but integer comparison in C is not type safe, so we have to wrap
> it.

Indeed, but current kernel applications do not use any flag to keep track
of the time stamp being valid or not, but most of the time rely on value
ZERO for that. So, if you want to really fix the places where this is used
that way, you must in theory add a flag for each kernel time based
variable. If you donnot add such a flag or donnot take time enough for
understanding _really_ what the author wanted to do, you run the risk
to break the code you are intending to fix against the 497.1 days problem.
And it seems it is what is currently happening.

Regards,
Gerard.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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