Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!oliveb!amiga!cbmvax!jesup From: jesup@cbmvax.UUCP (Randell Jesup) Newsgroups: comp.sys.amiga.tech Subject: Re: help with disk/tape device driver(s) Keywords: device drivers, SCSI Message-ID: <7470@cbmvax.UUCP> Date: 28 Jul 89 20:50:30 GMT References: <1006@olympic.oz> <5107@tekigm2.MEN.TEK.COM> <1048@olympic.oz> <4172@amiga.UUCP> <1072@olympic.oz> Reply-To: jesup@cbmvax.UUCP (Randell Jesup) Organization: Commodore Technology, West Chester, PA Lines: 43 In article <1072@olympic.oz> enno@olympic.oz (Enno Davids) writes: >In article <4172@amiga.UUCP>, kodiak@amiga.UUCP (Robert R. Burns) writes: >> tapes (BRU) does so via SCSI commands issued directly thru the tape drive >> thru the same exec device using the HD_SCSICMD command described in the >> 1.3 include file . We encourage all applications requiring >> access to something other than a magnetic disk on SCSI to use this command, >> and all writers of SCSI exec-level drivers to support it. > >This isn't hard to provide, but I find the choice of HD_SCSICMD (it's value) >to be a little kludgy. (What if you already have more commands than this? If >you don't you probably fill the command table with a bunch of dummy entries >because you have too few.) It was chosen to be sure no one was using that device command slot on a trackdisk-like driver. If you have a number fewer than that, you either make a specific check for HD_SCSICMD before consulting the table, or add a few null entries to your table. Not an awful lot of bytes. >My solution was to have a completely separate task doing the SCSI bus >management. Any device driver could still offer HD_SCSICMD by simply accepting >such commands and then passing them on to the SCSI task. This also means that >the SCSI access is no longer reliant on some particular device being mounted >(e.g tape restore to an unmounted hard drive, etc.). Just some thoughts. This is a fairly common solution to writing a device driver. Most drivers have a task handling the hardware, which is fed requests by the BeginIO vector of the device. Some have a second task, which is fed low-level "raw" requests (such as raw scsi commands) by the higher-level task. This does cost an extra task switch per command (about 400us). >Finally, a repeat question. Is there any other documentation that pertains to >the information in scsidisk.h/hardblocks.h other than the includes themselves? Well, not really, though if you send private mail with your needs I can probably scrounge you up some documents. There are some more verbose explanations of each of the fields in rigid disk blocks. There is no published documentation other than the includes at this time. Perhaps in an upcoming AmigaMail. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"