Subject: Re: problems with ahc vs. format command
To: Robert Elz <kre@munnari.OZ.AU>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 06/12/2001 18:36:13
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 <email@example.com>
> 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 ...
> (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