Re: why set a timer to expire at the current value of "jiffies"?

["Peter Teoh" <htmldeveloper@xxxxxxxxx>]

Sorry, I may wrong, just to throw some ideas for brainstorming:

The program u are looking at (arch/x86/kernel/pci-calgary_64.c) is a
watchdog.   Check this:

http://en.wikipedia.org/wiki/Watchdog_timer#cite_note-0

So accordingly, u are supposed to reset the timer of the watchdog, if
not the system will behave in a different way.   (eg, For certain
motherboard, the watchdog timer will reboot the whole system if
instructions streams are not detected at the hard-reset, but it will
not be triggered at soft-reset, or in Cisco router, the watchdog is to
continuously check that the router did not go into an infinite loop,
if timer not reset, it will reboot the whole OS).

but i did saw another patch where the mod_timer() is used to emulate
missing interrupts.   that was just a temporary workaround.   but i
think the usage of mod_timer() is very diverse, and hardware knowledge
comes into play in major way.

On Mon, Mar 31, 2008 at 5:19 PM, Mulyadi Santosa
<mulyadi.santosa@xxxxxxxxx> wrote:
> Hi Robert
>
>  On Mon, Mar 31, 2008 at 3:45 PM, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote:
>  >   sure, that's what i thought as well, but depending on the semantics
>  >  of how timers work, can't you imagine an implementation that checks
>  >  first and realizes right away that you're *already* at that time and
>  >  just invokes the handler immediately?  i mean, are people making that
>  >  kind of call to mod_timer() *assuming* that there will be a time lag,
>  >  even if it's a tiny one.  that strikes me as a dangerous assumption to
>  >  make, don't you think?
>
>  this is the point where I think sometimes we can't interpret what the
>  original code developer(s) really wanted to do just by looking at the
>  codes. It could be "that way", "this way" or none of both. In short
>  word, we have less justifications
>
>  >   the only other reason i can think of for the above is that someone
>  >  wants to call a handler *right now* or as soon as possible, but wants
>  >  to continue execution anyway.  in other words, it just happens to be a
>  >  way to asynchronously invoke a handler -- it just *looks* weird.
>
>  in some degree, I tend to agree on your above "speculation".


-- 
Regards,
Peter Teoh

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ