Nous pouvons écrire au niveau du noyau mais le fait d'insérer des lignes de code dans d'autres drivers comme sd.c (pour utiliser la méthode de l'export symbol) n'est pas voulu par notre client car il devrait recompiler le module à chaque changement ou mise a jour.
L'utilisation de FUSE est a mon avis trop haut niveau et cela serait trop couteux. Le but de ce projet est en fait d'avoir un hdd qui gererait le stockage de masse et entre le systeme et le hdd, le ssd simulerait une sorte de cache. Ainsi on pourrait bénéficier de la vitesse du ssd avec la capacité d'un hdd.
On était plus parti sur le fait de réimplémenter une fonction make_request en utilisant une struct bio (relative à la requete qu'un driver reçoit) en lui spécifiant la structure du device (SSD ou HDD) afin qu'elle soit traitée par son driver spécifique.
Mais c'est justement au niveau de la récupération de cette structure que ça bloque.
[^] # Re: FUSE
Posté par Dolby . En réponse au message Déléguer une requête à un driver pré-existant. Évalué à 1.
Nous pouvons écrire au niveau du noyau mais le fait d'insérer des lignes de code dans d'autres drivers comme sd.c (pour utiliser la méthode de l'export symbol) n'est pas voulu par notre client car il devrait recompiler le module à chaque changement ou mise a jour.
L'utilisation de FUSE est a mon avis trop haut niveau et cela serait trop couteux. Le but de ce projet est en fait d'avoir un hdd qui gererait le stockage de masse et entre le systeme et le hdd, le ssd simulerait une sorte de cache. Ainsi on pourrait bénéficier de la vitesse du ssd avec la capacité d'un hdd.
On était plus parti sur le fait de réimplémenter une fonction make_request en utilisant une struct bio (relative à la requete qu'un driver reçoit) en lui spécifiant la structure du device (SSD ou HDD) afin qu'elle soit traitée par son driver spécifique.
Mais c'est justement au niveau de la récupération de cette structure que ça bloque.