Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!caen!destroyer!wsu-cs!vela!vtrm01.uucp!dcope From: dcope@vtrm01.uucp Newsgroups: comp.unix.bsd Subject: Re: new new scsi release beta2 part 1 of 5 (fixed)SKIP Message-ID: <1992Sep28.130134.36@vtrm01.uucp> Date: 28 Sep 92 13:01:34 EST References: <1992Sep23.221352.16254@tfs.com> Organization: Vickers, Inc. - Troy, MI, USA Lines: 111 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.