From: dcope@vtrm01.uucp
Newsgroups: comp.unix.bsd
Subject: Re: new new scsi release beta2 part 1 of 5 (fixed)SKIP
Date: 28 Sep 92 13:01:34 EST
Organization: Vickers, Inc. - Troy, MI, USA

In article <1992Sep23.221352.16254@tfs.com>, julian@tfs.com (Julian Elischer) writes:
> This release of the new scsi system has been considerably neatenned up
> as far as the definitions of scsi arguments go.
> also supports cdrom.
> 

  [ a great scsi driver deleted]

> X	/dev/MAKEDEV
> XA replacement MAKEDEV that knows about these devices.
> X
> X
> X----------------------------------------------------------------
> XThis scsi system is designed to allow the re-use of top end drivers
> Xsuch as disk and tape drivers, with different scsi adapters.
> X
> XAs of writing this document, There are top end drivers working for:
> X----------------------------------------------------------------
> Xgeneric scsi disk
> Xgeneric scsi tape
> Xcd-rom (tested for SUN cd-rom only)
> XAEG Character recognition devices *
> XCalera Character recognition devices *
> XKodak IL900 scanner *
> XExabyte tape changer device.**
> X----------------------------------------------------------------
> X
> X
> XThere are also working bottom end drivers for:
> X----------------------------------------------------------------
> Xadaptec 1542 (and 1742 in 1542 mode)
> Xbustec 742a **
> X----------------------------------------------------------------
> X
> X
> XWork is proceeding on the following bottom end drivers:
> X----------------------------------------------------------------
> XFuture Domain (8 and 16 bit)****	hosler@tfs.com & rpr@oce.nl
> XWD7000****				terry@icarus.weber.edu
> Xseagate st01/st02****			overby@aspen.cray.com ?
> Xadaptec 174x ***			me
> XUltrastore ***				overby@aspen.cray.com & friend?
> X----------------------------------------------------------------
> X* drivers not made public (proprietary.. proof that the concept works though)
> X** driver not yet released but working.
> X*** just a dream so far.
> X**** some amount more than just a dream so far.
> X
> X
> X################## Using the scsi system ##################
> X------------minor numbers---------------
> XThis scsi system does not allocate minor numbers to devices depending
> Xon their SCSI IDs is any way. A devices minor number is dependant
> Xon the order in which it was found.
> Xe.g. the first tape found will become st0 (minor number 0)
> X	the second found will become st1 (minor number 16)
> X	the third will become st2 (minor 32) 
> X	etc.
> X
> XThese devices could be on the same scsi bus or different scsi busses.
> XThat would not change their minor numbers.
> X
> XIt is possible to run two different TYPES of scsi adapters at the 
> Xsame time and have st0 on one and st1 on another. (for example)
> X
> XThere is a scheme supported in which scsi devices can be 'wired in' even
> Xif they are not present or powered on at probe time. (see scsiconf.c)
> X
> X--------------getting started------------
> XIt should be possible to use the /dev entries for as0 as if they were 
> X/dev entries for sd0 and the old as bootblocks should
> Xcontinue to work if you are using an adaptec 1542b.
> X
> X--------------making devices------------
> XA changed version of /dev/MAKEDEV is supplied that
> Xcan be used to make devices sd[01234] and st[01234]
> X
> Xe.g. 
> Xcd /dev
> Xsh MAKEDEV sd0 sd1 sd2 st0 st1 cd0
> X

The problem with the supplied MAKEDEV file is it creates a major number of
(14).  This is also the number of the printer.  Did you ever try to print
to the tape drive.. does'nt work so well.

The tape ,which is a Digital tk50 device, works flawlessly.

> X
> XThe tape devices are as follows:
> Xrst0	basic raw device, will rewind on close
> Xnrst0	will not rewind on close
> Xerst0	will rewind and EJECTon close
> Xnerst0  will not rewind and WILL eject (some devices may rewind anyhow)
> X
> X------------future enhancements--------------
> XSome people have indicated that they would like to have the SCSI ID
> Xencoded into the minor number in some way, and
> Xthis may be supported at some timein the future, using
> Xminor numbers greater than 128. (or maybe a different major number)
> X
> XI will also be writing (probably) a generic scsi-error
> Xhandling routine that will be table driven, so that the routine can
> Xbe removed from each individual driver. With enough care,
> Xtwo similar devices with different error codes (quite common) could run
> Xthe same driver but use different error tables.
> X
I can be reached at (vtrm01!dcope@vela.acs.oakland.edu)

Don.

Newsgroups: comp.unix.bsd