Le fichier d'en-tête drivers/scsi/sg.h dans l'arborescence des sources
Linux contient une description de l'interface (ce qui suit est fondé sur la
version 1.1.68 du noyau)~:
struct sg_header
{
int pack_len;
/* longueur du paquet entrant <4096 (y compris en-tete) */
int reply_len; /* longueur maxi de reponse attendue <4096 */
int pack_id; /* numero id du paquet */
int result; /* 0==ok, sinon voir les codes errno */
unsigned int twelve_byte:1;
/* Force la longueur a 12 pour les commandes des groupes 6 & 7 */
unsigned int other_flags:31; /* pour usage futur */
unsigned char sense_buffer[16]; /* utilise seulement en lecture */
/* la commande suit puis les donnees de la commande */
};
Cette structure décrit comment une commande SCSI doit être traitée et disposer d'espace pour le résultat de son exécution. Les composants individuels de la structure seront abordés plus loin à la section sec-header .
La méthode générale pour échanger des données avec le pilote générique est
la suivante~: pour envoyer une commande à un périphérique générique ouvert,
il faut effectuer un write() d'un bloc composé de trois parties~:
struct sg_header
commande SCSI
donnees en sortie
Pour obtenir le résultat d'une commande, il faut effectuer un read()
d'un bloc composé des trois parties (similaires)~:
struct sg_header
donnees en entree
Il s'agit d'une vue générale du processus. Les sections qui suivent décrivent chaque étape en détail.
NOTE~: jusqu'à de récentes versions du noyau, il reste nécessaire de bloquer
le signal SIGINT entre les appels correspondants de write() et de
read() (i.e. par sigprocmask()). Un return après la partie
write() sans le read() suivant pour lire les résultats va bloquer
les accès suivants. Ce blocage de signal n'a pas encore été inclus dans le
code exemple. Evitez donc d'envoyer un SIGINT (par ˆC, par exemple) lors du
test de ceux-ci.
Chapitre suivant, Chapitre Précédent
Table des matières de ce chapitre, Table des matières générale
Début du document, Début de ce chapitre