On Tue, Jun 12, 2001 at 11:06:58PM +0700, Robert Elz wrote:
>     Date:        Mon, 11 Jun 2001 21:54:21 +0200
>     From:        Manuel Bouyer <bouyer@antioche.lip6.fr>
>     Message-ID:  <20010611215421.A337@antioche.eu.org>
> 
>   | OK, there are interger overflow problems in both drivers, for such a long
>   | (6 hours) timeout. ncr53c9x.c tried to deal with this, but it fails anyway
>   | for long timeouts, for hz <= 100.
>   | Can you try the attached patches ?
> 
> Leaving aside whether the patches fix the problem reported, I question
> whether sticking 64 bit arithmetic into relatively heavily used drivers
> in order to handle a once a month request (if that) is really the right
> way to go about it.
> 
> Rather than that, how about just accepting that if someone is asking for
> a timeout of more than an hour or so, the chances that they really want it
> to be highly accurate are vanishingly small (if you ask for an hour, whether
> the timeout goes off in 59:58 or 60:02 is unlikely to bother anyone), and
> so instead of doing 64 bit arithmetic (which is almost certainly compiler
> invoked library routines on most architectures), do ...
> 
> 	callout_reset(&scb->xs->xs_callout,
> 	    (newtimeout > 3*1000*1000 ?
> 		((newtimeout / 1000 + 1) * hz) : (newtimeout * hz) / 1000),
> 	    ahc_timeout, scb);
> 
> and so on?   Even then the 3M could be lots shorter with reasonable
> safety, to accomodate really high values of hz.   If you prefer to
> round to nearest, instead of the slightly safer up for timeouts, then
> make (newtimeout / 1000 + 1) * hz be ((newtimeout + 500) / 1000) * hz.

The question is whenever the test is really less expansive than the
64bit computation. I think on some platforms it may be more expensive.

Anyway scsipi should really provide a macro or inline function for this;
I'll look at this some day ...

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--