Re: gettimeofday question

[Russell King]

Eli Carter writes:
> And you described (in much better detail) the same problem I was talking
> about in the first email I sent today.

Ok, at least we've got the same picture that we're working from now.

> Yes, but it digs another to get the dirt to fill the first one. :/  for
> instance:
> 
> > 
> >         read_lock_xtime_and_ints();
> >         jiffies_1 = jiffies;
> >         counter_1 = counter;
> >         read_unlock_xtime_and_ints();
> 
> Time passes due to an interrupt handler.... but not a full jiffy, so
> jiffies hasn't changed.
> Also, what if this function is called with interrupts disabled?  (Is
> that legal?)  If so, we've broken the locking expected by the caller.

The calling function does indeed do the read_lock_xtime_and_ints() bit
for us.  However, we can always do a read_unlock(); sti(); read_lock_irq();
in do_gettimeofday().  Whether we want to or not is another matter,
especially as its not nice for a called function to explicitly enable
interrupts.

As for timer interrupts taking more than 10ms, yes, that is another
problem. ;(

> Comments?

This problem has a non-trivial solution, and I think whoever originally
wrote the x86 do_gettimeofday code decided that it wasn't worth finding
a solution to it.

--
Russell King ([e-mail])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html