Je pense qu'il y a une confusion entre ce que dit unix "Tout est fichier" et ce que fait le kernel.
"Tout est fichier" c'est pour l'user space. Le kernel doit représenter l'ensemble du système sous la forme de fichiers. Ça permet d'avoir un user space qui accède à tout, toujours de la même façons : Des fichiers dans une arborescence, j'ouvre les fichiers, j'ai un fd, ....
Mais le kernel, en interne, ne suis pas cette convention (et encore heureux). Un disque dur se comporte fondamentalement différemment d'un clavier, d'un écran (carte graphique) ou d'un périphérique réseau. (Et c'est bien pour ça qu'on a différent sous-système/drivers dans le kernel).
Quand tu fais un mount /dev/foo /tmp/mount, tu demandes au kernel de :
- prendre le périphérique block /dev/foo (le fait que tu puisses l'identifier comme un fichier dans une arborescence est sympa mais est sans rapport ici et rajoute de la confusion)
- trouver le bon système de fichier (FS)
- associer le contenu du périphérique block (exploité par le FS) au dossier /tmp/mount.
Ce qui est dans /tmp/mount est le "résultat" de FS(/dev/foo)
Mais quand tu lui passes un fichier standard en entrée, c'est peut-être la même chose pour toi (c'est accessible par un path, ton iso contient effectivement un FS,...) mais pour le kernel c'est complètement différent. Il n'a "rien" à passer au driver/FS, ton fichier standard est le "résultat" d'un autre FS dans un point de montage. Tu dois donc créer un autre couche d'abstraction qui "crée" un truc block à partir d'un fichier standard, et là ça marche.
cp, dd et cat fonctionne au niveau userspace, donc tout est fichier. Donc c'est effectivement transparent pour eux.
# Tout n'est pas fichier
Posté par GaMa (site web personnel) . En réponse au message Pourquoi mount (le syscall) n'accepte pas un fichier ordinaire. Évalué à 10.
Je pense qu'il y a une confusion entre ce que dit unix "Tout est fichier" et ce que fait le kernel.
"Tout est fichier" c'est pour l'user space. Le kernel doit représenter l'ensemble du système sous la forme de fichiers. Ça permet d'avoir un user space qui accède à tout, toujours de la même façons : Des fichiers dans une arborescence, j'ouvre les fichiers, j'ai un fd, ....
Mais le kernel, en interne, ne suis pas cette convention (et encore heureux). Un disque dur se comporte fondamentalement différemment d'un clavier, d'un écran (carte graphique) ou d'un périphérique réseau. (Et c'est bien pour ça qu'on a différent sous-système/drivers dans le kernel).
Quand tu fais un
mount /dev/foo /tmp/mount, tu demandes au kernel de :- prendre le périphérique block
/dev/foo(le fait que tu puisses l'identifier comme un fichier dans une arborescence est sympa mais est sans rapport ici et rajoute de la confusion)- trouver le bon système de fichier (FS)
- associer le contenu du périphérique block (exploité par le FS) au dossier
/tmp/mount.Ce qui est dans
/tmp/mountest le "résultat" de FS(/dev/foo)Mais quand tu lui passes un fichier standard en entrée, c'est peut-être la même chose pour toi (c'est accessible par un path, ton iso contient effectivement un FS,...) mais pour le kernel c'est complètement différent. Il n'a "rien" à passer au driver/FS, ton fichier standard est le "résultat" d'un autre FS dans un point de montage. Tu dois donc créer un autre couche d'abstraction qui "crée" un truc block à partir d'un fichier standard, et là ça marche.
cp,ddetcatfonctionne au niveau userspace, donc tout est fichier. Donc c'est effectivement transparent pour eux.Matthieu Gautier|irc:starmad