Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sfsup.UUCP
Path: utzoo!linus!decvax!bellcore!ulysses!mhuxr!mhuxn!mhuxm!sftig!sfsup!mjs
From: mjs@sfsup.UUCP (M.J.Shannon)
Newsgroups: net.arch,net.micro.mac,net.micro.68k
Subject: Bad Devices (was Re: timing loops)
Message-ID: <144@sfsup.UUCP>
Date: Sun, 23-Feb-86 00:14:47 EST
Article-I.D.: sfsup.144
Posted: Sun Feb 23 00:14:47 1986
Date-Received: Wed, 26-Feb-86 03:41:50 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <6780@boring.UUCP> <9645@amdcad.UUCP> <295@hropus.UUCP> <9835@amdcad.UUCP>
Organization: AT&T Information Systems, Summit N.J.
Lines: 15
Xref: linus net.arch:2401 net.micro.mac:4804 net.micro.68k:1446

As a kernel hacker, I would maintain that a device that requires a
certain latency and neither rejects further commands nor signals an
iterrupt until it's ready is a botch.  Why patch software when the
hardware CAN do it right?  Software is not the answer to hardware
designer ineptitude.  Even if it has to be done at the board level,
the proper choice is to add the hardware to disable access to the
device until its latency period is over.
-- 
	Marty Shannon
UUCP:	ihnp4!attunix!mjs
Phone:	+1 (201) 522 6063

Disclaimer: I speak for no one.

"If I never loved, I never would have cried." -- Simon & Garfunkel