Meta

Où ? Quand ?

Le projet doit être rendu par mail à nobelis@polytech.unice.fr avant le 26 novembre. Les TDs du 5, 12 et 19 novembre seront consacrés au projet, mais vous devrez aussi avancer dans le projet en dehors des heures de TD.

Le mail doit avoir pour sujet Projet ASY 07 - Nom du binôme. Pour être sûr que j'ai bien reçu votre projet, vous pouvez m'envoyer le mail avec une demande d'accusé de réception (je répondrai à toutes ces demandes). N'oubliez pas d'attacher votre projet au mail (!)

Comment ?

  • Le projet est à faire préférablement en binôme.

  • La lisibilité du code source sera prise en compte dans la notation : le code devra être commenté, en anglais ou en français, mais également bien indenté. Pour la mise en forme du code source, essayez de vous conformer à ces consignes. Vous pouvez si vous le souhaitez utiliser le programme Lindent pour gérer les indentations.

  • Le projet sera rendu dans une archive (zip ou tar.bz2), déja compilé pour la version du noyau que nous utilisons en TD (2.4.21-47.EL). Seront également présents dans l'archive :
    • le code source (!)
    • un Makefile ayant au minimum pour cibles :
      • build (cible par défaut compilant le module, l'installant et effectuant un depmod),
      • init (initialisation à effectuer une seule fois pour que votre module fonctionne : répertoire ou device à créer, etc...),
      • insert (insérant votre module dans le noyau),
      • delete (retirant votre module du noyau),
      • clean (nettoyant tout ce que vous jugez utile de nettoyer, en particulier ce que vous avez créé avec la cible init)
    • un fichier readme.txt contenant :
      • les consignes d'utilisation de votre module (e.g. le nom de votre filesystem, etc...)
      • les améliorations supplémentaires que vous avez apporté au projet (voir ci dessous).
      • vos remarques sur le projet. Soyez honnêtes sur les limitations et les problèmes de votre code, la notation en tiendra compte.

  • La grille de notation du projet vous sera communiquée la séance du 12 novembre.

CALCFS

Le projet consiste à implémenter un système de fichiers virtuel faisant office de calculette.

Les chiffres et les opérateurs sont des dossiers qui sont combinés pour former des chemins contenant le résultat de l'opération. Seules les opérations de base sont supportées : addition, soustraction, multiplication, division. Un chemin n'indique qu'une seule opération, il n'est donc pas possible de composer les opérations entre-elles.

Voici un exemple d'utilisation :

[root@localhost calcfs]# make insert
[root@localhost calcfs]# mount -t calcfs none fs
[root@localhost calcfs]# ls fs
0/  1/  2/  3/  4/  5/  6/  7/  8/  9/
[root@localhost calcfs]# cd fs
[root@localhost fs]# ls 1
0/  2/  4/  6/  8/  divise_par/  fois/   plus/
1/  3/  5/  7/  9/  egale        moins/
[root@localhost fs]# cat 1/egale
1
[root@localhost fs]# ls 1/2/
0/  2/  4/  6/  8/  divise_par/  fois/   plus/
1/  3/  5/  7/  9/  egale        moins/
[root@localhost fs]# cat 1/2/egale
12
[root@localhost fs]# ls 1/2/fois
0/  1/  2/  3/  4/  5/  6/  7/  8/  9/
[root@localhost fs]# ls 1/2/fois/8
0/  1/  2/  3/  4/  5/  6/  7/  8/  9/  egale
[root@localhost fs]# ls 1/2/fois/8/3
0/  1/  2/  3/  4/  5/  6/  7/  8/  9/  egale
[root@localhost fs]# cat 1/2/fois/8/3/egale
996

Le résultat final s'explique donc par 12 * 83 = 996. Comme on peut le voir sur l'exemple, le contenu des dossiers est toujours l'ensemble des éléments qu'il est possible d'ajouter à l'opération (on accepte les overflows). Le fichier egale contient le résultat de l'opération, seule la fonction read est à implémenter pour ce fichier.

Indications

  • remplir une structure struct file_system_type Certains d'entre vous ont déjà trouvé cette technique : vous pouvez utilisez la macro static DECLARE_FSTYPE(variable, nom système de fichier, pointeur vers une fonction read_super, 0). Cette macro déclare une variable globale statique nommée variable de type struct file_system_type dont les membres seront initialisés suivant les paramètres de la macro.
  • quelques précisions sur
    • readdir : cette fonction est appelée chaque fois qu'un listing d'un dossier est demandé. Ce dossier est représenté par le membre d_inode du dentry contenu dans le paramètre filp. Pour chaque fichier contenu dans ce dossier, readdir doit appeler la fonction de callback passée en troisième paramètre. Les paramètres de la fonction de callback, généralement nommée filldir, sont triviaux à l'exception du cinquième : ce paramètre n'est le numéro d'inode du fichier concerné que si vous pouvez le connaître à cet instant. Dans le cas contraire, ce ne sera qu'un numéro unique obtenu avec la fonction iunique, qui ne sera pas le numéro final d'inode. Pas plus d'infos sur ce comportement, malheureusement.
      La fonction filldir appelle la fonction lookup si l'inode relative au fichier n'est pas présente dans le cache.
    • lookup : cette fonction, appelée par filldir, a pour premier paramètre l'inode parente du fichier recherché et pour second paramètre un dentry représentant le fichier.
      La fonction doit vérifier si le fichier, dont le nom est contenu dans le dentry (membre d_name), est bien un fichier contenu par le dossier parent. Si c'est le cas, il faut créer une inode pour ce fichier (fonction new_inode), puis ajouter cette inode au dentry passé en paramètre et au cache des inodes (fonction d_add). Notons que dans votre cas, les entrées du cache n'expirent à priori jamais.
      Après l'appel à d_add, le membre d_inode du dentry contient un pointeur vers l'inode créé. Cette même inode a un numéro définitif (membre i_ino) qui est celui que vous voyez avec un ls -i.
  • données attachées à une inode Vous allez sûrement avoir besoin d'associer des données à une inode. Pour cela, deux solutions s'offrent à vous :
    • stocker ces données + le numéro de l'inode concernée dans une liste chainée. Dans ce cas, vous devrez écrire une fonction de recherche qui renverra les données associées à un numéro d'inode passé en paramètre.
    • stocker ces données dans la structure inode elle-même. Pour cela, vous disposez dans cette structure d'un membre nommé u qui est une union contenant entre autres un champ de type void * nommé generic_ip. Vous pouvez stocker ce que vous souhaitez dans ce champ, mais n'oubliez pas de l'allouer et de le libérer.
  • quand libérer ces données attachées ? Votre super block dispose d'une méthode put_inode dans son membre s_op : cette fonction est appelée quand le compteur d'utilisation d'une inode est décrémenté (membre i_count). Notez cependant que cette fonction est appelée avant que le compteur soit décrémenté : donc si ce compteur est à 1 dans cette fonction, vous pouvez considérer que l'inode ne va plus être utilisée, et ainsi libérer les données attachées.

Cette question constitue le rendu minimal du projet. Si vous voulez l'améliorer, vous pouvez faire la ...

1ère extension

À la racine de notre système de fichier, on ajoute maintenant un nouveau fichier, nommé memory. Cette mémoire contient tous les derniers calculs effectués par le pilote (c'est à dire tous ceux terminant par egale).

[root@localhost fs]# ls .
0/  1/  2/  3/  4/  5/  6/  7/  8/  9/ memory
[root@localhost fs]# cat memory
aucun resultat
[root@localhost fs]# cat 1/2/fois/8/3/egale
996
[root@localhost fs]# cat 2/5/divise_par/2/egale
12
[root@localhost fs]# cat memory
1) 996 (12*83)
2) 12  (25/2)

On stockera tous les calculs effectués dans une liste chaînée (n'oubliez pas la fonction sprintf). Le fichier memory implémentera donc juste la fonction read pour renvoyer une forme affichable de sa liste.

1ère extension (version++)

Le fichier memory n'est pas existant lors de la création du système de fichier. Laissez à l'utilisateur la possibilité de le créer (on ne peut le créer qu'à la racine). Le fichier nouvellement créé ne contiendra alors que les opérations effectuées après sa création.

[root@localhost fs]# ls .
0/  1/  2/  3/  4/  5/  6/  7/  8/  9/
[root@localhost fs]# cat 1/2/fois/8/3/egale
996
[root@localhost fs]# touch memory
[root@localhost fs]# cat memory
aucun resultat
[root@localhost fs]# cat 2/5/divise_par/2/egale
12
[root@localhost fs]# cat memory
1) 12  (25/2)

Autres extensions :

Si vous avec encore du temps libre, n'hésitez pas à rajoutez d'autres fonctionnalités à votre calcfs, elles seront prise en compte dans la notation dans une certaine mesure (points bonus). Cependant restez dans la limite du raisonnable (i.e. ne dépassez pas 200 lignes de code pour les extensions).

Docs

Docs du TP7 : VFS, VFS (alt), Signatures des fonctions de l'API du kernel.

Nouvelle(s) doc(s) : Création de fichiers dans le VFS (attention, certaines parties sont pour un noyau 2.6 uniquement).

-- NicolasNobelis - 11 Nov 2007

Revision: r1.3 - 12 Nov 2007 - 07:57 - NicolasNobelis
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WIKIDeptinfo? Send feedback