Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!uw-beaver!tikal!amc!eric
From: eric@amc.UUCP (Eric McRae)
Newsgroups: comp.sys.amiga
Subject: Re: SCSI device drivers
Message-ID: <367@amc.UUCP>
Date: Fri, 17-Apr-87 13:32:36 EST
Article-I.D.: amc.367
Posted: Fri Apr 17 13:32:36 1987
Date-Received: Sun, 19-Apr-87 11:05:31 EST
References: <1548@umd5.umd.edu>
Reply-To: eric@amc.UUCP (Eric McRae)
Distribution: na
Organization: Applied Microsystems Corp.; Redmond, Wa.
Lines: 30

In article <1548@umd5.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes:
>.....  One of the wonderfull things about SCSI systems is that you can
>hang multiple controllers on the SCSI bus.  Things like disk controllers,
>tape controllers, ethernet controllers, etc.
>
>...  Hopefully, there are
>two seperate drivers for such products; the driver to talk to the SCSI host
>adaptor and a higher level disk device driver that call upon the SCSI driver
>to talk to the SCSI bus.
>
>It there a standard for the interface to the SCSI driver?
>
>The usefullness of the SCSI bus is pretty much eliminated if you can't talk
>to any of the (other) devices on it. ...

I agree.  My company markets a SCSI interface for our emulators that
really screams.  We have no problems running on machines with general
purpose SCSI drivers but those are few.  I sit in front of a beautiful
Sun 3/50 with a SCSI port that we can't use because the only access they
provide is through their disk driver.

If you're writing a SCSI driver for anything, design it for the general
case and provide that interface.  There is very little overhead in doing
so and you'll have more industry support for your product in the long run.

Eric McRae	Engineering Fellow, Applied Microsystems Corporation
USENET:		..uw-beaver!tikal!amc!eric (Ignore path info above)
ATT:		(206) 882-2000
USNAIL:		PO Box 97002 Redmond, WA 98073-9702
MISSILES: 	122 8 27 W / 47 39 14 N