ecrire un driver

• 

  bob1969

  14 novembre 2004 à 16h48 #933

  bonjour,

  Comme question, je me suis toujours posé, c’est comment fonctionne l’architecture d’un driver amigaOS (perif simple)

  par exemple le lecteur de disquette.il y a le device,le handler et la mountlist (obsolete ?). mais comment çà fonctionne ensemble ?

  Car je suis intéressé par l’écriture d’un driver modeste de perifs comme des lecteurs carte memoire sur port parallele.

  en modifiant l’existant pour l’adapter aux perif d’aujourd’hui

  un bricolage quoi !

  merci de vos lumieres

  bob1969

  dans l’ombre

  

  jchap

  14 novembre 2004 à 20h29 #24596

  C’est informations semblent top-secretes et hélas les derniers en possession d’éléments de réponse ont été retrouvés morts, après d’atroces souffrances…

  (Juste pour laisser le thread un peu plus longtemps sur la page d’accueil)

  

  Lanza

  23 novembre 2004 à 18h22 #24597

  Yurf, ben le mieux serait que tu mettes la main sur le RKRM Device Manual (sur le CD Developer 2.1 par exemple). Ça doit être expliqué dedans avec plus de précision et d’exhaustivité que ce que pourra trouver comme réponses ici, à mon avis. Mais en anglais, forcément.

  

  sg2

  23 novembre 2004 à 19h04 #24598

  Bonjour,

  Une librairie est un exécutable particulier, avec une structure de « jump table » qui contient les adresses de chaque fonction de la librairie. Toutes les librairies doivent au moins implémenter quelques fonctions obligatoires genre init, open, close, expunge, plus leurs propres fonctions (ce à quoi elles servent .

  Un device est une librairie particulière, qui ajoute quelques fonctions supplémentaires, principalement beginio() et abortio().

  Pour prendre l’exemple que tu cites (driver de périphérique de stockage), le driver va avoir comme client principalement un filesystem (OFS, FFS, SFS, etc).

  Les transactions vont se faire de la manière suivante :

  – le FS ouvre une unit particulière du device (exemple : unit 0, 1 etc) en appelant sa fonction Open().

  – le FS construit des IORequests contenant un code de commande (CMD_READ, CMD_FORMAT, CMD_WRITE, etc) et les éventuels pointeurs sur les données nécessaires à ces commandes (exemple : pour un CMD_READ, il faut donner au device le n° et le nombre de blocks à lire, et un pointeur sur le buffer dans lequel ranger les données lues). Le FS passe cet IORequest au device en appelant sa fonction BeginIO().

  – le driver fait ce qu’il veut avec l’IORequest : il la traite de suite, la range dans une file, la file à une tâche fille etc. en fonction du boulot à faire

  – lorsque le boulot est fait, il notifie le FS en lui PutMsg() son IORequest mise à jour avec un code de statut

  Pour un premier overview je pense que c’est suffisant

  Remarque : tu peux très bien faire une appli qui s’adresse directement à un device sans passer par un filesystem, en construisant toi même une IORequest, en faisant ton OpenDevice et ton BeginIO… C’est exactement ce que fait scsispeed, qui teste un device avec des CMD_READ, donc sans overhead de filesystem, alors que diskspeed appelle la fonction Read() d’un filesystem, donc teste la performance du combiné FS + device.

  Si tu veux en savoir plus, n’hésite pas à demander.

  Amigalement,

  —

  Stéphane Guillard