Oui, les systèmes de fichiers sous Linux peuvent être implémentés en tant que modules du noyau. Mais il y a aussi l'interface FUSE (Filesystem in USErspace), qui peut permettre à un processus d'espace utilisateur normal d'agir comme un pilote de système de fichiers. Si vous prototypez un nouveau système de fichiers, l'implémenter d'abord à l'aide de l'interface FUSE pourrait faciliter les tests et le développement. Une fois que les composants internes du système de fichiers ont été élaborés sous forme FUSE, vous pouvez alors commencer à en implémenter une version de module de noyau optimisée pour les performances.
Voici quelques informations de base sur l'implémentation d'un système de fichiers dans l'espace noyau. C'est assez vieux (de 1996!), Mais cela devrait au moins vous donner une idée de base du genre de choses que vous devrez faire.
Si vous choisissez d'aller sur la route FUSE, voici libfuse, l'implémentation de référence du côté espace utilisateur de l'interface FUSE.
Pilote de système de fichiers en tant que module du noyau
Fondamentalement, la fonction d'initialisation de votre module de pilote de système de fichiers doit simplement appeler une register_filesystem()fonction et lui donner comme paramètre une structure qui inclut un pointeur de fonction qui identifie la fonction dans votre pilote de système de fichiers qui sera utilisée comme première étape dans l'identification de votre système de fichiers tapez et montez-le. Il ne se passe plus rien à ce stade.
Lorsqu'un système de fichiers est en cours de montage et que le type de système de fichiers est spécifié pour correspondre à votre pilote ou que la détection automatique du type de système de fichiers est effectuée, la couche Virtual FileSystem du noyau (VFS pour faire court) appellera cette fonction. Il dit essentiellement "Voici un pointeur vers une représentation au niveau du noyau d'un périphérique bloc Linux standard. Jetez-y un œil, voyez si c'est quelque chose que vous pouvez gérer, puis dites-moi ce que vous pouvez en faire."
À ce stade, votre pilote est censé lire tout ce dont il a besoin pour vérifier que c'est le bon pilote pour le système de fichiers, puis renvoyer une structure qui inclut des pointeurs vers d'autres fonctions que votre pilote peut faire avec ce système de fichiers particulier. Ou si le pilote du système de fichiers ne reconnaît pas les données sur le disque, il est censé renvoyer un résultat d'erreur approprié, puis VFS signalera une défaillance dans l'espace utilisateur ou - si une détection automatique de type de système de fichiers est effectuée - demandera à un autre système de fichiers pilote à essayer.
Les autres pilotes du noyau fourniront l'interface de périphérique de bloc standard, de sorte que le pilote du système de fichiers n'aura pas à implémenter la prise en charge matérielle. Fondamentalement, le pilote du système de fichiers peut lire et écrire des blocs de disque à l'aide de fonctions standard au niveau du noyau avec le pointeur de périphérique qui lui est attribué.
La couche VFS s'attend à ce que le pilote du système de fichiers mette un certain nombre de fonctions standard à la disposition de la couche VFS; certains d'entre eux sont obligatoires pour que la couche VFS fasse quoi que ce soit de significatif avec le système de fichiers, d'autres sont facultatifs et vous pouvez simplement retourner un NULL à la place d'un pointeur vers une telle fonction facultative.
Oui, un pilote de noyau peut gérer un système de fichiers.
La meilleure solution pour simuler un prototype de système de fichiers est d'utiliser FUSE. Et après, vous pouvez penser à le transformer en pilote de noyau.
Wikipedia => https://en.wikipedia.org/wiki/Filesystem_in_Userspace
Source => https://github.com/libfuse/libfuse
un tutoriel => https://developer.ibm.com/articles/l-fuse/
la source
Oui, cela se fait généralement à l'aide d'un pilote de noyau qui peut être chargé en tant que module du noyau ou compilé dans le noyau.
Vous pouvez consulter des pilotes de système de fichiers similaires et leur fonctionnement ici .
Ces pilotes utilisent probablement des fonctions internes du noyau pour accéder aux périphériques de stockage sous forme de blocs d'octets, mais vous pouvez également utiliser des périphériques de blocs tels qu'exposés par les pilotes dans les dossiers des périphériques de bloc et des périphériques de caractères .
la source
Vous pouvez utiliser fuse, pour créer un système de fichiers utilisateur, ou écrire un module noyau. C'est plus facile à faire avec les fusibles, car vous avez le choix des langues, et vous ne planterez pas le noyau (et donc tout le système).
Les modules du noyau peuvent être plus rapides, mais la première règle d'optimisation est la suivante: ne le faites pas avant d'avoir testé le code de travail. La seconde est comme ça: ne le faites pas avant d'avoir la preuve que c'est trop lent. Et le troisième: ne le conservez pas sauf si vous avez la preuve qu'il le rend plus rapide / plus petit.
Et oui, le noyau a déjà des pilotes pour le matériel, vous ne les réimplémentez pas.
la source
pivot_root, car il y a encore des inodes occupés dans les initramfs./initdémarré à partir d'un initramfs s'exécutera (je pense)/initaprès pivot_root, pour transférer le contrôle aux vrais root FS/init. Mais un binaire FUSE ne pouvait pas se remplacer par execve si l'accès à la racine FS dépendait du processus FUSE répondant au noyau. Eh bien, peut-être en amorçant d'abord la pagecache, mais cela ne semble pas fiable.