mlelstv@immd4.informatik.uni-erlangen.de (Michael van Elst ) (07/14/89)
enno@olympic.oz (Enno Davids) writes: >In article <5107@tekigm2.MEN.TEK.COM>, phils@tekigm2.MEN.TEK.COM (Philip E Staub) writes: >Now I complicate the matter by acquiring a SCSI tape drive and adding it to >the system. To simplify the software I want to keep the tape and disk driver >code separate. To do this I must provide some alternate way for the tape >driver code to access the SCSI bus independantly of the disk driver. What about the way that is implemented into trackdisk.device ? There exists a semaphore (within disk.resource) that arbitrates access to the hardware registers. As each unit task uses the disk, it requests this semaphore and releases it after the operation. There should be no need for a seperate task, that handles the physical IO. You should never be able to do physical IO on the task that does the SendIO since waiting within beginio is a bad thing. >as PA_SIGNAL). Unfortunately, these fields are set at the time the reply >port is created, and can thus be quite wrong. Now, there are two driver tasks that request the scsi server (or more tasks if you use a task per device unit). Each task must have it's own ReplyPort and the server just replies to the messages. I don't see the problem. Just to repeat, you should not access the hardware on the callers context. >Other questions I originally asked were about what I could and couldn't do >in the device driver. I believe for instance that it is not kosher to use >dos.library either directly or otherwise. Is this correct? No, since you are loaded by a DOS process you may make dos calls on your init routine. You might avoid dos calls within your beginio/abortio streams since they are executed on the callers context that might be an Exec task. You need to use the dos call CreateProc if your unit task (then process) needs to use the dos.library (maybe to LoadSeg overlays as the printer.device). >Anyone from CBM care to comment about any of this? Would be nice. >Enno. Michael van Elst E-mail: UUCP: ...uunet!unido!fauern!immd4!mlelstv