ecrire un driver

4 sujets de 1 à 4 (sur un total de 4)

  • bob1969

    • Messages : 988
    #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

    • Messages : 434
    #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

    • Messages : 895
    #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

    • Messages : 34
    #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

4 sujets de 1 à 4 (sur un total de 4)

  • Vous devez être connecté pour répondre à ce sujet.

Forums AmigaOS, MorphOS et AROS Développement ecrire un driver

Amiga Impact