Tout n’est pas fichier

Apr 19

« « Sécurité du processus de boot | Power of choice » »

Par peck

Niveau :
Résumé : syscall

Il paraît que sous unix tout est fichier. Vous allez voir que ce n'est pas tout à fait vrai.

La seule interface du noyau avec ses processus est la table des appels systèmes, dont voici la liste pour linux (et les prototypes en C). Vous y trouverez en gros 3 catégories : les appels liés aux fichiers, les appels liés aux processus, les appels liés au temps. Dans les fichiers on trouve entre autre le réseau, et dans les processus on trouve entre autre la gestion de la mémoire et des signaux. Donc sous unix tout est fichier ou processus ou temps (souvenez-vous du temps où on l'appelait time sharing system).

Malgré leur grand nombre, les appels système ne font finalement que peu de choses. Quelques opérations de base, et puis c'est tout. En fait la grande majorité du code de linux est appelé à travers des lectures/écritures sur des fichiers.

Le code du driver de votre disque dur est appelé lors de la lecture d'un répertoire. Le code de nombreux drivers est appelé lors de l'utilisation d'un fichier dans /dev, le code de configuration de linux est appelé lors de l'utilisation de /sys ... Ce qui est beau dans cette histoire c'est qu'on ne s'en rend pas compte, les méthodes utilisées sont toujours les mêmes (open, read, write ...)

Notez quand même que tout cela forme une API du noyau un peu plus vaste que les appels systèmes : les numéros de bloc dans /dev, les noms dans /sys, le format de fichier dans /proc, ne sont pas interchangeables. C'est une API au dessus de l'API fichier. C'est à cause ou plutôt grâce à elle qu'on dit que tout est fichier.

Mais retenez surtout ceci : tout est fichier ou processus ou temps.

none

Comments

R@OUL

April 19th, 2010 at 11:01 PM


Tout est fichier (sauf quand on bidouille le noyau)
philippe lhardy

April 21st, 2010 at 5:29 PM


et inversement tout est dans le noyau… sauf quand on bidouille dans le fichiers…
sylvainulg

May 10th, 2010 at 11:11 AM


Quid des interfaces réseaux ? eth0 et consoeurs sont, si je ne buse, les seules à ne jamais apparaître dans /dev. Je sors ma loupe … un petit "strace ifconfig" révèle un accès à /proc/net/if_inet6 qui contient normalement un court descriptif de la configuration réseau en cours :
[code]/home/sylvain> cat /proc/net/if_inet6
00000000000000000000000000000001 01 80 10 80 lo
fe80000000000000020272fffe436672 03 40 20 80 wlan0
fe80000000000000021cc0fffe2c54b9 02 40 20 80 eth0[/code]

Pourtant, ce fichier ne sert au programme qu’à vérifier l’existence d’un support IP6 … ce qui lui permet de créer un socket (okay, c’est un descripteur de fichier). Ce qui suit n’est pas joli-joli, mais c’est assez typique de ce qui se passe sur un système Unix lorsque l’objet que l’on tente de manipuler n’est en fait pas un fichier :[code] ioctl(5, SIOCGIFFLAGS, {ifr_name="eth0", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
ioctl(5, SIOCGIFHWADDR, {ifr_name="eth0", ifr_hwaddr=00:xx:c0:xx:54:xx}) = 0
ioctl(5, SIOCGIFMETRIC, {ifr_name="eth0", ifr_metric=0}) = 0
ioctl(5, SIOCGIFMTU, {ifr_name="eth0", ifr_mtu=1500}) = 0
[/code]

Eh oui, le socket ne servira ici qu’à interroger les modules noyau qui s’en chargent sans jamais vraiment utiliser des lectures ou des écritures. Voilà un fichier bien curieux, non ? Je ne me risquerais pas à y appliquer un sys_fsetxattr, tout descripteur de fichier qu’il soit.

J’avais fait le même genre de bricole avec les cartes graphiques nvidia qui ont tendance à utiliser uniquement mmap(/dev/nvidia0ctl) pour accéder directement aux registres de la carte graphique. Une variation sur le thème "Quand on jamais utilisé qu’un marteau, tous les problèmes sont des clous", en somme.
peck

May 10th, 2010 at 2:07 PM


Très bonne remarque :-)
En effet les interface réseau ne sont pas des fichiers, même si bash permet d’émuler leur fonctionnement à travers un fichier (http://shudder.daemonette.org/source/BashNP-Guide.txt).
Elles ne sont accessible qu’au travers de socket qui n’ont pas de représentation fichier.
De plus elles sont configurable en partie à travers une communication socket netlink et en partie à travers de certains fichiers dans /proc

Mais bon, une socket ce n’est jamais qu’un fichier qui n’existe pas dans le système de fichier :-)

Sinon il est parfaitement logique pour un driver de carte graphique d’utiliser mmap sur le fichier device étant donné que physiquement c’est sous forme d’un mapping sur le bus qu’on accès à ces registres. Ça rentre bien dans le moule du tout fichier.

Par contre il est vrai que l’abus d’ioctl est un travers lié à cet usage exclusif des fichiers. Ça rend l’api non structurée et difficile à faire évoluer et à utiliser.
Erin

December 5th, 2010 at 10:16 PM


Excusez moi, mais il semblerai qu’il y ai une erreur dans cet article:
"Il paraît que sous unix tout est fichier"
"dont voici la liste pour linux"
Pour rappel, linux is not unix ^^. le principe de tout est fichier effectivement existant sous unix (suffit de refaire les tests sous *BSD ou solaris) n’est plus vrai comme vous l’avez demontre, sous linux, cependant le nom meme de linux implique que cela n’a jamais ete la pretention de linux de copier unix, mais d’etre different (meme les libc sont differentes ^^).
Peck

December 5th, 2010 at 10:43 PM


Je suis d’accord, linux n’est qu’une imitation plutôt réussie d’unix. Mais pour rappel c’est GNU is not unix.

Je cite : "sous unix tout est fichier ou processus ou temps" c’est valable quel que soit l’unix. Prenons la liste des appels système de freebsd (qui est un unix) http://fxr.watson.org/fxr/source/kern/syscalls.c et on constate exactement le même raisonnement.

Linux Attitude