Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Programmation : Assembleur - initilisation d'un gestionnaire
(Article écrit par Frédéric Delacroix et extrait d'Amiga News - mars 1998)
|
|
Le mois dernier, je vous ai tracé les grandes lignes de fonctionnement
d'AmigaDOS. Il est temps aujourd'hui de passer à l'étude concrète du fonctionnement d'un gestionnaire de périphérique.
Structure d'un gestionnaire
J'en ai déjà un peu parlé, les gestionnaires sont des processus. Ils sont chargés, quand besoin est, par la routine LoadSeg()
d'AmigaDOS depuis des fichiers exécutables, qui résident généralement dans le répertoire L:. Avant d'aborder l'écriture
de ce programme, voyons comment il est déclaré au sein d'AmigaDOS. Vous le savez probablement, pour reconnaître un nouveau
périphérique, le DOS a besoin d'une liste de montage ("mountlist"), ainsi nommée parce qu'elle est utilisée par la commande "mount".
Au temps des DOS pré-2.1, tous les gestionnaires étaient identifiés dans le fichier (texte) Devs:Mountlist.
Les choses ont évolué depuis et la commande "mount" est devenue un peu plus intelligente, ces gestionnaires sont décrits dans
des fichiers textes séparés, habitant dans le répertoire Devs:DOSDrivers.
Dans ce fichier on trouve principalement le nom du gestionnaire à charger (handler = L:machin-handler), la pile qui lui est
nécessaire (stack...), la priorité, le vecteur global (j'en parlerai plus loin), et de nombreux autres paramètres, parmi
lesquels "device=truc.device", dont la seule présence indique au DOS que le gestionnaire en question est un système de fichiers.
La programmation d'un gestionnaire de fichiers étant une toute autre paire de manches, je laisserai cela de côté.
Tous ces paramètres peuvent être dans le fichier lui-même, ou dans les types d'outil de l'icône (ceux-ci ont la priorité).
Le paramètre spécial "Mount" indique (=1) qu'il faut initialiser le gestionnaire tout de suite ou (=0) lors du premier accès.
Mais en quoi consiste ce montage ? Le DOS répertorie simplement les informations de la liste de montage dans sa liste interne
qui contient les spécifications de tous les périphériques, les volumes et les assignations. Cette liste est constituée de
structures DosList, qui se déclinent en trois appellations (struct DeviceNode, Devinfo ou DeviceList). La première de ces
structures est pointée par le champ dl_DevInfo de la structure DosInfo (c'est son seul champ documenté), elle-même pointée
par le champ rn_Info de la structure Root-Node, qui peut être considérée comme une extension de la structure DosLibrary et
pointée par le champ dl_Root de celle-ci (ouf).
Certains de ces pointeurs sont des BPTR. Attention donc, il faut les multiplier par 4 avant usage. D'ailleurs, depuis le
Kickstart 2.0, l'accès à cette liste de DosList est protégée par un sémaphore, il ne faut donc pas aller se servir soi-même
dans la liste de la dos.library. Il faut désormais passer par les fonctions GetDeviceProc() et FreeDeviceProc(). Elles
peuvent également servir à résoudre des assignations ou obtenir des informations sur un volume, la fonction DeviceProc() étant
considérée comme obsolète depuis le Kickstart 2.0. La fonction GetDeviceProc() obtient le sémaphore et retourne un pointeur
sur une structure DevProc (ne vous mélangez pas les pinceaux avec toutes ces structures) qui contient, entre autres, un
pointeur sur la structure DeviceProc (ou DosList) du gestionnaire.
Pour ce qui est de la structure DosList, on y retrouve essentiellement les informations de la liste de montage. Je ne vais parler
que de ce qui concerne les gestionnaires. Le champ dol_Type indique s'il s'agit d'un périphérique (DLT_DEVICE), d'une assignation
(DLT_DIRECTORY) ou d'un volume (DLT_VOLUME). Depuis la version 2.0 du système, il y a également les assignations déférées (DLT_LATE) et
non liantes (DLT_NONBINDING), dont je parlerai peut-être dans un prochain article. Il y a aussi DLT_PRIVATE, qui comme son nom
l'indique...
Le champ dol_Task pointe sur le champ pr_MsgPort de la structure Process du gestionnaire (c'est ce qu'on appelle le ProcessID),
dol_Handler contient un pointeur BCPL sur le nom (chaîne BCPL) du fichier à charger pour activer le gestionnaire, dol_StackSize
contient la taille de sa pile, dol_Priority sa priorité en tant que tâche Exec. Le champ dol_Startup sert à passer des paramètres
au démarrage du gestionnaire : il correspond au champ spécial "Startup=" de la liste de montage. On peut y mettre ce que l'on
veut (pour un gestionnaire de périphérique, toujours). Le champ dol_SegList contient la liste de segments du gestionnaire s'il
a déjà été chargé. C'est le résultat de LoadSeg() qui servira à libérer la mémoire en cas de mort du gestionnaire. dol_Name
contient (BSTR) le nom du gestionnaire et il reste le champ dol_GlobVec.
Ce fameux GlobVec est une réminiscence du BCPL, langage étrange s'il en est. Pour nous, il faut toujours mettre sa valeur à -1,
ou éventuellement à -2 (depuis le Kickstart 2.0). La différence entre les deux se situe au niveau du verrouillage de la liste
des DosLists pendant l'initialisation du gestionnaire : avec -1, la liste est totalement verrouillée et aucun accès n'est
permis, ce qui peut poser des problèmes de blocage si le gestionnaire a besoin d'accéder à un autre gestionnaire pendant son
initialisation. Avec -2, la liste est juste verrouillée en lecture seule, et de telles opérations deviennent possibles.
Tout ceci se range dans la catégorie "haute sorcellerie".
Le message de démarrage
Donc, lorsqu'il est chargé depuis le disque, le programme du gestionnaire commence son exécution comme un quelconque programme.
Pour savoir ce que le DOS compte faire de lui, il doit attendre et lire le message de démarrage spécial qui lui est envoyé à
son port pr_MsgPort. Il s'agit d'un DosPacket, dont le contenu est le suivant : dp_Arg1 contient le nom du périphérique
tel qu'il a été invoqué, dp_Arg2 le contenu du champ dol_Startup de la structure DosList et dp_Arg3 un pointeur BCPL sur
la structure DosList.
Le gestionnaire doit alors procéder à toutes les initialisations nécessaires. Il peut également créer un nouveau processus
(cas du gestionnaire de console). Quoiqu'il en soit, il doit, soit mettre dans le champ dol_Task son ProcessID, soit
laisser ce champ à zéro et fournir un pointeur sur un autre port de message dans le champ dp_Arg4 du message de démarrage.
Si toute l'initialisation se passe bien, il faut répondre au paquet avec DOSTRUE en dp_Res1. Sinon, c'est DOSFALSE en dp_Res1
et le code d'erreur en dp_Res2, et il faut quitter. Si tout se passe bien, il n'y a plus qu'à attendre l'arrivée de nouveaux
DosPackets et à les traiter.
Ce sera l'objet le mois prochain de la dernière partie de cette série d'articles, avec (enfin) l'écriture d'un vrai gestionnaire
de périphérique. Bon courage.
|
