Résolution des liens actifs

La sémantique des appels systèmes stat, lstat et astat sur les liens actifs suit les résolutions suivantes :

$\bullet$

stat() $\rightarrow$ statut du fichier.

$\bullet$

lstat() $\rightarrow$ statut du fichier.

$\bullet$

astat() $\rightarrow$ statut du fichier.

$\bullet$

stat() $\rightarrow$ statut du fichier pointé par le lien symbolique.

$\bullet$

lstat() $\rightarrow$ statut du lien symbolique.

$\bullet$

astat() $\rightarrow$ statut du lien symbolique.

$\bullet$

stat() $\rightarrow$ statut du fichier pointé par l'exécution du programme d'indirection.

$\bullet$

lstat() $\rightarrow$ statut du programme d'indirection pointé par le lien actif.

$\bullet$

astat() $\rightarrow$ statut du lien actif.

Étant donné la forte ressemblance entre les liens symboliques et les liens actifs dans la façon d'être stockés dans le système de fichier, la méthode de résolution d'alink est elle aussi très proche. Elle se découpe en deux étapes successives. La première consiste à traiter le lien actif comme un lien symbolique afin d'obtenir le chemin du programme d'indirection. La deuxième étape est constituée de l'exécution de ce programme et de la récupération du nouveau chemin donné.

Pour réaliser la première résolution, nous avons tout simplement dupliqué celle des liens symboliques en prenant soin de renommer les fonctions et constantes de façon cohérente (ex: S_IFLNK en S_IFALNK). À partir de là nous devions donc :

$\bullet$

lancer un nouveau processus

$\bullet$

lire la sortie du processus fils

Techniquement cela s'est traduit par l'utilisation de différentes fonctions et appels systèmes servant chacun à réaliser une tâche précise :

$\bullet$

kernel_thread
créé un nouveau thread dans le kernel qui se met à exécuter une fonction passée en paramètre. Nous l'avons utilisé pour initialiser le lancement d'un processus fils

$\bullet$

do_pipe
créé un pipe, tout comme la fonction pipe de la libc. Nous l'avons par la suite partagé entre le processus fils et père pour récupérer la sortie du programme d'indirection (le fils)

$\bullet$

set_fs
change le mode d'adressage pour que les appels systèmes acceptent des pointeurs de l'espace kernel, au lieu d'accepter uniquement ceux de l'espace d'adressage utilisateur. Cette fonction a été utilisée quand nous avons dû allouer de la mémoire à partir du kernel

$\bullet$

sys_close
ferme un descripteur de fichier, tout comme la fonction close de la libc. Et ceci nous a permit de nettoyer les descripteurs de fichiers ouvert à l'aide du pipe

$\bullet$

sys_read
lit des données à partir d'un descripteur de fichier, et les met dans un buffer. Dans notre cas, le descripteur de fichier était le pipe

$\bullet$

sys_wait4
bloque le processus courant pour attendre la fin de l'exécution d'un processus fils précisé en argument. Ce qui a permit de récupérer dans le père le code de retour du fils

$\bullet$

sys_dup2
redéfini un descripteur de fichier en un autre. Son utilisation courante est de dérouter la sortie standard d'un processus vers un autre descripteur de fichier (comme un pipe)

$\bullet$

do_execve
remplace le thread kernel courant par l'exécution d'un programme passé en argument. C'est donc à cette fonction que nous avons demandé de lancer le programme d'indirection