Re: poor change in ncr53c8xx/linux-2.1.104

Gerard Roudier (groudier@club-internet.fr)
Mon, 8 Jun 1998 19:50:47 +0200 (MET DST)


On Tue, 9 Jun 1998, Paul Gortmaker wrote:

> > >
> > > So, if getting small delays without extra overhead is that important, then
> > > this patch is even more efficient than the original (103 and earlier)
> > > behaviour, and I trust you will agree after comparing the resulting
> > > assembly.
> >
> > No. Right solution is to look over ncr53c8xx.c, and kill DELAY()
> > altogether. It can be replaced by udelay() and mdelay()s one by one. I
> > did it and patch is waiting somewhere in the mail que. It makes code
> > more efficient and much more readable.
>
> I suspect that DELAY has not already been replaced in this fashion so that
> the driver core can be easily diff'ed against the FreeBSD version, making
> maintenance of the driver less of a headache. The fact that DELAY is in
> upper case tends to hint to me that it was a FreeBSD macro originally.

No problem for diffing versions, since drivers are now very different.
BTW, I do prefer the BSD upper case form of DELAY/udelay, for the simple
reason that using such pauseq is not good and this way, we cannot miss
them.

Why having 2 different functions for waiting micro versus milli-seconds?
This is kind of complexity and is a source of weird errors, IMO.
Imagine some mdelay() being used instead of udelay() or the opposite, and
all this stuff written in lowercase...

> Also note that there would be *no* difference between the efficiency of the
> generated assembly from the patch I just posted (DELAY as a macro) and the
> removal of DELAY that you advocate. (Readability is probably improved when
> large delay values are involved, however...)

We need DELAYS is driver in order to deal with hardware timings or some
short delays that will be complex to implement asynchronously.
No need to waste time on this topic. It is a very simple issue and
there is lots of far more important things to do to improve Linux.

Gerard.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu