Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site dmsd.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!hplabs!hpda!dmsd!bass
From: bass@dmsd.UUCP (John Bass)
Newsgroups: net.arch,net.micro.mac,net.micro.68k
Subject: Re: Bad Devices (was Re: timing loops)
Message-ID: <221@dmsd.UUCP>
Date: Wed, 26-Feb-86 02:52:14 EST
Article-I.D.: dmsd.221
Posted: Wed Feb 26 02:52:14 1986
Date-Received: Fri, 28-Feb-86 22:02:54 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <6780@boring.UUCP>
Organization: DMS Design, San Jose Office, CA
Lines: 26
Xref: watmath net.arch:2631 net.micro.mac:4866 net.micro.68k:1521

> 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

DO IT RIGHT ???? ^&%^%@%(*) Right depends on the goals and requirements.
From were many of us sit RIGHT is LOW COST, LOW POWER, SMALL SIZE, and
a dozen other reasons for using a KNOWN hardware/software tradeoff to
reduce componet counts. From Marty's IVORY TOWER in AT&T land he has a very
obscure view of RIGHT -- a company that produces $300 power supplies that
deliver 40 watts (they do last 30 years with minor service though) and other
common place electronics (like telephones) that are now 1/3 the cost once the
repairability and service life requirements have been reduced by other vendors.
Not that I especially like some of the CHEAP phones -- but a good trend overall.

Timing loops are FAIR GAME for any lowcost design -- and can be VERY general
with the aid of a subroutine that takes as it's argument the min number of
time units to spin out.

John Bass