Cc: David P. Reed <dpreed@...>, David Woodhouse <dwmw2@...>, Rene Herman <rene.herman@...>, Zachary Amsden <zach@...>, H. Peter Anvin <hpa@...>, Christer Weinigel <christer@...>, Ondrej Zary <linux@...>, Bodo Eggert <7eggert@...>, Ingo Molnar <mingo@...>, Paul Rolland <rol@...>, Pavel Machek <pavel@...>, Thomas Gleixner <tglx@...>, <linux-kernel@...>, Ingo Molnar <mingo@...>, rol <rol@...>
It's not careful: it's a croc. It's an ugly hack, an abuse of process,
and totally unnecessary. Read my comment about delays (next).
Wrong. It's a delay. It's a delay measured in I/O cycles, but still a
delay. Doing I/O to get a delay, even if the delay is intended to be
measured in I/O cycles, is hackery of the most inexperienced sort. It's
the sort of thing junior programmers get boxed in the ear for. There's
no satisfactory reason to do it that way.
If the hardware required an intermediate junk I/O, that would be a
reason to do one, but it doesn't, does it? It requires a delay. It's
written thus in all of the application notes.
Wrong again. Of course one knows how long the delay should be. The bus
speed is known. The specifications of the hardware is known. Do the
math you (the programmer writing the driver, not Alan) lazy sluggard,
and use a delay. It baffles commonsense to say you don't know how long
it should be.
Well, frankly, the development process could stand a little more of it.
The sooner we stop denying that this is a hack, the sooner we can fix it.
--
