Ein generischer SCSI-Treiber (2)

Weder TOS selbst noch die TOS-kompatiblen Betriebssysteme bieten von sich aus die Möglichkeit zur direkten Kommunikation mit SCSI-Peripheriegeräten.

Für den ATARI gibt es mehrere Möglichkeiten, ein SCSI-Gerät zum Medienauswurf zu bewegen. Wenn es um Wechselplatten geht, kann man sich vorteilhaft eines XHDI-kompatiblen Treibers bedienen, der von Hause aus eine entsprechende Funktion bereitstellt. Bei anderen Geräten, insbesondere bei Streamern und CD-ROM-Laufwerken, kommt man auf diesem Weg allerdings nicht weiter. Hier bietet sich die Nutzung des SCSIDRV-Interfaces an.

Wie man das SCSI-Kommando EJECT zum Medienauswurf über den generi-schen SCSI-Treiber an alle angeschlossenen SCSI-Geräte schickt, soll Thema dieser Ausgabe sein. Die Grundlagen wurden bereits in [1] gelegt. Dort wurden die wichtigsten Aufrufe des SCSIDRV vorgestellt, wie er in [2] und [3] implementiert ist.

Erläuterungen Programmlisting

Das Listing zum Programm EJEC-TALL.TOS ist ausführlich dokumentiert, daher möchte ich hier nur die wesentlichen Operationen ansprechen. Um EJECTALL.C compilieren zu können, sind die Headerfiles zum SCSIDRV erforderlich, wie sie in [2] enthalten sind.

Nun zum Programmablauf: Zunächst wird nach dem cookie "SCSI" gesucht, wie er vom SCSIDRV angelegt wird. Der Parameter zu diesem cookie ist ein Pointer auf eine Liste aller Routinen, die vom SCSIDRV bereitgestellt werden. Zu diesen Routinen zählen auch InquireSCSIO und InquireBusQ. Mit diesen Aufrufen werden von EJEC-TALL alle Geräte ermittelt, die an den verfügbaren SCSI-Bussen angeschlossen sind. Für jedes dieser Geräte wird mit Open() ein Kommunikationskanal geöffnet, über den anschließend mit Out() das EJECT-Kommando abgesetzt wird. Eine Datenübertragung per DMA findet in diesem Fall nicht statt. Um unnötige Wartezeiten zu vermeiden, wird im Kommandoblock von EJECT das Immediate-Bit gesetzt. Dadurch wird erreicht, dass ein Gerät nach Erhalt des EJECT-Kommandos schnellstmöglich den Abschluß der Operation meldet. Abschließend wird das bei Open() erhaltene Handle mit Close() freigegeben, da die Zahl der Handies des SCSIDRV ähnlich wie bei den GEMDOS-Dateioperationen begrenzt ist.

Vor jedem Aufruf des SCSIDRV wird in den Supervisor-Modus gewechselt, der direkt nach dem Aufruf wieder verlassen wird. Zwar wäre es auch möglich, das gesamte Programm im Supervisor-Modus auszuführen, dies ist jedoch nicht ratsam. In einer Multitasking-Umgebung findet in der Regel kein Taskwechsel statt, falls sich der

Prozessor im Supervisor-Modus befindet. Daher sollte der Supervisor-Modus nur dort genutzt werden, wo unbedingt erforderlich. In den Supervisor-Modus gelangen kann man entweder mit der GEMDOS-Funktion Super() oder dem XBIOS-Aufruf SupexecQ. Der Einfachheit halber wurde in EJECTALL SuperQ verwendet. Im allgemeinen ist es jedoch ratsamer, auf SupexecQ zurückzugreifen.

Verzicht auf Fehlerprüfung

Um EJECTALL möglichst kurz und einfach zu halten, wurde auf einige Dinge verzichtet, die für eine ernsthafte Applikation unbedingt erforderlich sind. So werden Fehler bei der Ausführung des SCSI-Kommandos nicht weiter berücksichtigt.

Hier bietet es sich an, das Ergebnis von Out() zu überprüfen und eventuell eine Fehleranalyse anhand der Daten von REQUEST SENSE vorzunehmen, wie sie im Fehlerfall nach dem Aufruf von Out() im entsprechenden Puffer abgelegt werden. Dieser Puffer wird bei Bedarf vom SCSIDRV gefüllt, da REQUEST SENSE vom Treiber im Fehlerfall automatisch aufgerufen wird.

Mit Hilfe des SCSI-Kommandos IN-QUIRY ließe sich zunächst ermitteln, um welchen SCSI-Gerätetyp es sich eigentlich handelt. Man könnte so denn für den ATARI gibt es mehrere Möglichkeiten, ein SCSI-Gerät zum Medienauswurf zu bewegen. Wenn es um Wechselplatten geht, kann man sich vorteilhaft eines XHDI-kompatiblen Treibers bedienen, der von Hause aus eine entsprechende Funktion bereitstellt. Bei anderen Geräten, insbesondere bei Streamern und CD-ROM-Laufwerken, kommt man auf diesem Weg allerdings nicht weiter. Hier bietet sich die Nutzung des SCSIDRV-Interfaces an.

Wie man das SCSI-Kommando EJECT zum Medienauswurf über den generischen SCSI-Treiber an alle angeschlossenen SCSI-Geräte schickt, soll Thema dieser Ausgabe sein. Die Grundlagen wurden bereits in [1] gelegt. Dort wurden die wichtigsten Aufrufe des SCSIDRV vorgestellt, wie er in [2] und [3] implementiert ist.

Erläuterungen zum Programmlisting

Das Listing zum Programm EJECTALL.TOS ist ausführlich dokumentiert, daher möchte ich hier nur die wesentlichen Operationen ansprechen. Um EJECTALL.C compilieren zu können, sind die Headerfiles zum SCSIDRV erforderlich, wie sie in [2] enthalten sind.

Nun zum Programmablauf:

Zunächst wird nach dem Cookie "SCSI" gesucht, wie er vom SCSIDRV angelegt wird. Der Parameter zu diesem cookie ist ein Pointer auf eine Liste aller Routinen, die vom SCSIDRV bereitgestellt werden. Zu diesen Routinen zählen auch InquireSCSI() und InquireBus(). Mit diesen Aufrufen werden von EJEC-TALL alle Geräte ermittelt, die an den verfügbaren SCSI-Bussen angeschlossen sind. Für jedes dieser Geräte wird mit Open() ein Kommunikationskanal geöffnet, über den anschließend mit Out() das EJECT-Kommando abgesetzt wird. Eine Datenübertragung per DMA findet in diesem Fall nicht statt. Um unnötige Wartezeiten zu vermeiden, wird im Kommandoblock von EJECT das Immediate-Bit gesetzt. Dadurch wird erreicht, dass ein Gerät nach Erhalt des EJECT-Kommandos

schnellstmöglich den Abschluß der Operation meldet. Abschließend wird das bei Open() erhaltene Handle mit Close() freigegeben, da die Zahl der Handies des SCSIDRV ähnlich wie bei den GEMDOS-Dateioperationen begrenzt ist.

Vor jedem Aufruf des SCSIDRV wird in den Supervisor-Modus gewechselt, der direkt nach dem Aufruf wieder verlassen wird. Zwar wäre es auch möglich, das gesamte