Path: utzoo!attcan!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!vsi1!daver!bungi.com!news Newsgroups: comp.sys.nsc.32k Subject: Structuring SCSI Message-ID: <9009251704.AA10568@manatee.UUCP> Date: 25 Sep 90 21:04:33 GMT Sender: news@daver.bungi.com Lines: 82 Approved: news@daver.bungi.com I found the following technique very helpful in trying to structure a SCSI device driver, so I thougth I would share it with the group. The NCR 53C700 SCSI processor can be programmed in a language they call "SCSI SCRIPS". Since this language is quite device independent but SCSI specific, it also makes nice way of expressing a psuedo code outline for any SCSI device driver. If this is of interrest call NCR's Information Hot-Line 1-800-525-2252 and ask for the NCR-53C700 Programmers Guide and NCR-53C700 Data Manual. The Programmers Manual also includes well commented SCSI SCRIP code for a sample initiator and target. Before I tried this I was having great difficulty keeping straight all the numerious states and error conditions. By the way, the 53C700 is now available in a PGA package (previously was 160-pin QFP only) . Also NCR just announced a 53C710 which is basicly a more general purpose 5C3700. In case you didn't know, a 53C7XX is a $50-60, 2-MIPS, RISC based SCSI I/O Processor on a chip. Change of focus: The following are some thoughts I put together to help me visualize a comprehensize SCSI subsystem in relation to Minix. Constructive ideas, thoughts, suggestions, either pro or con are welcome. All other comments should be directed to the bit bucket. Best regards, johnc SCSI Implementation Thoughts: ----------------------------- (1) SCSI Tasks (5) Host Adaper Tasks ---------- ----------------- DP8490_task FS <-Msg-> disk_device (2) <-Msg-><-+-> o Initiator_mode <---+ } <= Intr tape_device +-> o ReSelect_mode <---+ } printer_device o Target_mode (3) <---+ } processor_device (4) | WORM_device AIC6250_task | CDROM_device <-Msg-><-+-> o Initiator_mode <-+ | } <= Intr Other_device +-> o ReSelect_mode <-+ | } o Target_mode (3) <-+ | } | | Amoeba (3) <-Msg-> <------------------------+-+ (1) Directory /dev determines mapping of device name to device major-minor and hence SCSI task process number, unit number (ie line). (2) First task of SCSI group to run. Initialization section contains code to establish overall configuration (ie. mapping of all major-minor device numbers to bus device scsi_id, lun). (3) It appears that the host adapter target_mode must communicate with an Amoeba task only (and server process by implication), whereas the host adapter initiator_mode can communicate with either a SCSI task or an Amoeba task. If the target_mode were employed with the FS an outstanding read would have to exist, blocking the FS to other processes. Had not thought of it before, but Amoeba can provide a 'named' means of raw device access which bypasses the FS .!!??. (4) Perhaps processor_device task is really Amoeba..??.. (5) SCSI-II device command descriptions. Device SCSI Class X3T9.2 Section --------- ---------------------- -------------- Disk Direct-Access 8 Tape Sequential-Access 9 Printer Printer 10 Processor Processor 11 WORM Write-Once Read-Multiple 12 CDROM Read-Only Direct-Access 13 Other unique, eg. IO bus board ? -- --