Le noyau Linux a-t-il besoin d'un système de fichiers pour fonctionner?
Mon avis est oui, il le fait, car toute exposition utile au monde extérieur (mode processeur non privilégié) nécessiterait d'abord un processus en cours d'exécution dans le monde extérieur. Cela nécessiterait un système de fichiers, même un système de fichiers temporaire en RAM.
Un autre ingénieur n'est pas d'accord avec moi, mais je n'arrive pas à le prouver au-delà de tous les cas (inconnus de moi).
La réponse à cette question dépend-elle de la définition de "courir"?
C'est une question plutôt étrange car vous n'exécutez pas le noyau comme vous exécutez un programme. Le noyau est une plate-forme sur laquelle exécuter des programmes. Bien sûr, il existe du code de configuration et d'arrêt, mais il n'est pas possible d'exécuter le noyau seul. Il doit toujours y avoir un processus "init" principal. Et le noyau paniquera s'il n'est pas là. Si init tente de quitter le noyau, il paniquera également.
Ces jours-ci, le processus init est quelque chose comme systemd. Sauf indication contraire, le noyau essaiera d'exécuter un programme à partir d'une liste d'emplacements commençant par /sbin/init. Voir le paramètre init ici http://man7.org/linux/man-pages/man7/bootparam.7.html en cas d'urgence, vous pouvez démarrer Linux avec init=/bin/bash. Mais remarquez comment vous spécifiez toujours un fichier sur le système de fichiers à exécuter.
Ainsi, le noyau paniquera s'il démarre et n'a pas de système de fichiers car sans celui-ci, il n'y a aucun moyen de charger init.
Une certaine confusion peut survenir à cause d'une situation de poulet et d'oeuf où le noyau doit charger des pilotes pour accéder à son système de fichiers. Pour contourner cela, un disque virtuel initial est chargé à partir d'une image sur le disque contenant des pilotes vitaux et des scripts de configuration. Ils sont exécutés avant le chargement du système de fichiers. Mais ne vous y trompez pas, le disque virtuel initial est lui-même un système de fichiers. Avec un disque virtuel initial /init est appelé (qui est stocké sur le disque virtuel initial). Dans de nombreuses distributions, c'est finalement ce qui appelle /sbin/init. Encore une fois sans système de fichiers, cela est impossible.
La réponse dépendra de savoir si vous entendez littéralement sans système de fichiers ou si la question est destinée à être interprétée un peu différemment de la façon dont elle est effectivement formulée. Les réponses pour de légères variations dans l'interprétation de la question sont:
- L'exécution de Linux sans aucun périphérique bloc est entièrement réalisable et utile pour certains cas d'utilisation spécialisés.
- L'exécution de Linux sans système de fichiers va nécessiter la réécriture de certaines parties du code du noyau et il est peu probable que ce soit un effort utile.
- Exécuter Linux sans utiliser de descripteurs de fichier va demander beaucoup d'efforts. Je suis sûr que cela ne vaudra pas l'effort.
Les raisons pour lesquelles vous auriez à réécrire des parties du code du noyau pour créer un système fonctionnel sans système de fichiers sont les suivantes:
- Chaque thread a un répertoire racine et un répertoire de travail actuel qui doit pointer vers un système de fichiers.
- Les programmes sont lancés par l'appel système
execvequi a besoin d'un exécutable d'un système de fichiers. - Le noyau crée un système de fichiers basé sur la mémoire pendant le processus de démarrage.
Après le démarrage d'un programme à l'aide de execve, il est possible de démapper l'exécutable à partir duquel il a été démarré, mais pour le faire sans le planter immédiatement, il faut d'abord créer un mappage de mémoire exécutable qui n'est pas ' t soutenu par un fichier, et il doit l'initialiser avec du code utile avant d'y sauter et de démapper l'exécutable.
Ainsi, un programme en mode utilisateur en cours d'exécution peut exister dans un état où il n'a aucun mappage de mémoire sauvegardé par des fichiers et il peut fermer tous les descripteurs de fichiers sauvegardés par des fichiers. Il ne peut pas arrêter d'avoir un répertoire racine et un répertoire de travail actuel, mais il peut s'abstenir de ceux-ci.
Donc, bien que dans cet état, vous puissiez implémenter du code du noyau pour extraire le système de fichiers de sous le programme et le faire continuer à fonctionner, cela ne semble pas utile. Et entrer dans cet état final sans passer par un état intermédiaire d'utilisation d'un système de fichiers va être encore plus de travail sans aucun avantage utile.
ne configuration utile pour certains cas d'utilisation spécialisés
Il peut être utile d'éviter l'utilisation de périphériques bloc. Lors du démarrage, le noyau crée un système de fichiers mémoire et peut également remplir ce système de fichiers avec le contenu d'une archive cpio avant d'exécuter init. De cette façon, vous pouvez exécuter un système entièrement à partir d'un système de fichiers basé sur la mémoire sans aucun périphérique de bloc pour le sauvegarder.
Cela peut être utile pour les systèmes où vous ne voulez conserver aucun état et comme le système pour démarrer à partir d'une table rase lors du redémarrage.
Bien sûr, le noyau et l'archive cpio doivent en quelque sorte exister en mémoire avant de donner le contrôle au noyau. Comment ils y sont arrivés est un travail pour le chargeur de démarrage. Le chargeur de démarrage aurait pu charger ceux-ci à partir d'un périphérique bloc même si le système en cours d'exécution n'utilise pas de périphériques bloc. Mais il est également possible pour le chargeur de démarrage d'acquérir le noyau et l'archive cpio sans utiliser un périphérique bloc, par exemple en démarrant sur le réseau.
Sous Linux, presque chaque périphérique est un fichier , vous devez donc avoir un système de fichiers pour l'exécuter.