Ce document est con�u pour aider les utilisateurs de Linux et d'Internet qui d�sirent apprendre en faisant. Bien que ce soit un bon moyen d'acqu�rir des comp�tences, quelquefois cela laisse de singuli�res lacunes dans la connaissance des bases -- lacunes qui peuvent rendre difficile la r�flexion cr�ative ou perturber fortement, par manque d'un mod�le mental clair sur ce qu'il devrait se passer.
J'essaierai de d�crire clairement, dans un langage simple, comment tout marche. La pr�sentation sera adapt�e aux personnes qui utilisent Unix ou Linux sur du mat�riel de type PC. Cependant, je ferai ici couramment r�f�rence � 'Unix' : ce que je d�crirai se retrouvera sur toutes les plates-formes et sur toutes les variantes d'Unix.
Je suppose que vous utilisez un PC avec un processeur de type Intel. Les d�tails diff�rent quelque peu si vous utilisez un processeur Alpha ou PowerPC ou une autre machine Unix, mais les concepts de base restent les m�mes.
Je ne voudrais pas r�p�ter les choses, alors vous allez devoir faire attention, mais cela veut dire que vous retiendrez chaque mot que vous lirez. C'est une bonne id�e que de tout parcourir rapidement la premi�re fois ; vous devrez y revenir et relire un certain nombre de fois afin de dig�rer ce que vous avez appris.
C'est un document en permanente �volution. Je pr�vois d'ajouter des chapitres en r�ponse aux feedbacks, ainsi vous pourrez p�riodiquement le passer en revue.
Si vous lisez dans l'espoir d'apprendre comment 'hacker', vous devrez lire How To Become A Hacker FAQ. Il y a beaucoup de liens vers d'autres ressources utiles.
Les nouvelles versions de 'Unix and Internet Fundamentals HOWTO' seront post�es p�riodiquement dans comp.os.linux.help et news:comp.os.linux.announce et news.answers. Elles pourront �tre t�l�charg�es � partir de divers sites Linux WWW ou FTP, y compris la page d'accueil du LDP.
Vous pouvez acc�der � la derni�re version (en anglais) de ce document sur le World Wide Web via l'URL http://sunsite.unc.edu/LDP/HOWTO/Unix-Internet-Fundamentals-HOWTO.html.
Si vous avez des questions ou des commentaires � propos de ce document, vous pouvez envoyer vos courriers �lectroniques � Eric S. Raymond, � esr@thyrsus.com. Toutes suggestions ou critiques seront les bienvenues. Seront sp�cialement appr�ci�s les liens hypertexte vers des explications plus d�taill�es ou vers des concepts propres. Si vous trouvez des erreurs dans ce document, faites-le moi savoir afin que je puisse les corriger dans la nouvelle version. Merci.
Votre ordinateur poss�de un processeur � l'int�rieur duquel se font r�ellement les calculs. Il poss�de une m�moire interne (ce que les gens DOS/Windows d�signent par ``RAM'' et que les gens UNIX d�signent souvent par ``core''). Le processeur et la m�moire r�sident sur la carte m�re qui est le coeur de votre ordinateur.
Votre ordinateur poss�de un �cran et un clavier. Il a un (ou des) disque(s) dur(s) et un lecteur de disquettes. L'�cran et vos disques ont des cartes contr�leur que l'on connecte sur la carte m�re et qui aident l'ordinateur � piloter ces p�riph�riques externes. Votre clavier est trop simple pour n�cessiter une carte s�par�e ; le contr�leur est int�gr� dans le ch�ssis du clavier.)
Nous d�crirons plus tard en d�tails comment fonctionnent ces p�riph�riques. Pour l'instant, quelques notions de base afin de garder � l'esprit comment ils fonctionnent ensemble :
Tous les �l�ments internes de votre ordinateur sont connect�s par un bus. Physiquement, le bus est ce sur quoi vous connectez vos cartes contr�leur (carte vid�o, contr�leur disque, carte son si vous en avez une). Le bus est l'autoroute emprunt�e par les donn�es entre votre processeur, votre �cran, votre disque et le reste.
Le processeur, qui fait tout marcher, ne peut r�ellement voir tous les �l�ments directement ; il doit communiquer avec eux via le bus, le seul sous-syst�me qui soit effectivement tr�s rapide, qui acc�de directement � la m�moire (le core). Afin que les programmes puissent s'ex�cuter, ils doivent �tre en m�moire core.
Lorsque votre ordinateur lit un programme ou une donn�e sur le disque, il se passe r�ellement les choses suivantes : le processeur utilise le bus pour envoyer une requ�te de lecture du disque � votre contr�leur de disque. Quelques instants apr�s, le contr�leur de disque utilise le bus pour signaler � l'ordinateur qu'il a lu la donn�e et qu'il l'a mise � un certain endroit de la m�moire. Le processeur peut utiliser le bus pour aller chercher ce qu'il y a � cet endroit de la m�moire.
Votre clavier et votre �cran communiquent �galement avec le processeur via le bus mais d'une mani�re plus simple. Nous exposerons cela plus loin. Pour l'instant vous en savez suffisamment pour comprendre ce qu'il se passe lorsque vous allumez votre ordinateur.
Un ordinateur sans programme qui s'ex�cute est juste un tas inerte d'�lectronique. La premi�re chose que doit faire un ordinateur lorsqu'il est allum� est de d�marrer un programme sp�cial appel� syst�me d'exploitation. Le travail du syst�me d'exploitation est d'aider les autres programmes de l'ordinateur � travailler, en traitant les d�tails m�prisables du contr�le du mat�riel de l'ordinateur.
Le processus de d�marrage du syst�me d'exploitation est appel� booting (originalement c'�tait bootstrapping (la�age des chaussures), allusion � la difficult� d'enfiler soi m�me ses chaussures `par les lacets'. Votre ordinateur sait comment booter car les instructions de boot sont stock�es dans un de ses composants, le composant BIOS (ou Basic Input/Output System).
Le composant BIOS dit o� aller chercher, � une place fixe sur le disque dur de plus basse adresse (le disque de boot), un programme sp�cial appel� chargeur de boot (boot loader) (sous Linux le chargeur de boot est appel� LILO). Le chargeur de boot est charg� en m�moire puis lanc�. Le travail du chargeur de boot est de d�marrer le syst�me d'exploitation r�el.
Le chargeur fait cela en allant chercher un noyau, en le chargeant en m�moire et en le d�marrant. Lorsque vous bootez Linux et voyez "LILO" sur l'�cran suivi par une succession de points, c'est qu'il charge le noyau. (Chaque point signifie qu'il vient de charger un autre bloc du disque du code du noyau.)
(Vous pouvez vous demander pourquoi le BIOS ne charge pas le noyau directement -- pourquoi ces deux �tapes du processus avec le chargeur de boot ? C'est que le BIOS n'est pas vraiment intelligent. En fait il est carr�ment stupide, et Linux ne l'utilise jamais apr�s avoir boot�. A l'origine, j'ai programm� sur des PC 8-bits primitifs avec de petits disques : litt�ralement ils ne pouvaient acc�der � suffisamment de disque pour charger le noyau directement. L'�tape du chargeur de boot vous permet de d�marrer plusieurs syst�mes d'exploitation � partir de diff�rents emplacements de votre disque, dans le cas o� Unix n'est pas assez bon pour vous.)
Une fois que le noyau d�marre, il doit chercher autour de lui, trouver le reste du mat�riel et �tre pr�t pour ex�cuter des programmes. Il fait cela non pas en fouillant � des adresses m�moire ordinaires, mais � des ports d'Entr�e/Sortie -- des adresses sp�ciales du bus, sens�es avoir une carte contr�leur de p�riph�riques en attente de commandes � cet endroit. Le noyau ne fouille pas au hasard ; il a un ensemble de connaissances qui lui permet de savoir ce qu'il est sens� trouver ici, et comment les contr�leurs r�pondraient s'ils �taient pr�sents. Ce processus est appel� Exploration automatique.
La plupart des messages que vous voyez au moment du boot sont l'exploration de votre mat�riel par le noyau � travers les ports d'Entr�e/Sortie, le chiffrage de ce qui est disponible et l'adaptation � votre machine. Le noyau Linux est extr�mement bon pour cela, meilleur que la plupart des autres Unix et tellement meilleur que DOS ou Windows. En fait, beaucoup de vieux adeptes de Linux pensent que l'ing�niosit� des explorations de Linux lors du boot (qui lui permettent de s'installer relativement simplement) ont �t� une raison de s'�panouir dans le monde des exp�riences des Unix libres pour attirer une masse critique d'utilisateurs.
Mais rendre le noyau compl�tement charg� et s'ex�cutant n'est pas la fin du processus de boot ; c'est juste la premi�re �tape (quelquefois appel�e niveau d'ex�cution 1 (run level 1)).
L'�tape suivante du noyau est de s'assurer que vos disques sont OK. Les syst�mes de fichiers sur disques sont des choses fragiles ; s'ils ont �t� endommag�s par une panne mat�rielle ou par une coupure soudaine d'alimentation �lectrique, il y a de bonnes raisons de r�tablir l'int�grit� avant que votre Unix ne puisse aller plus loin. Nous parlerons plus tard de ce que l'on dit � propos de comment les syst�mes de fichiers peuvent devenir mauvais.
L'�tape suivante du noyau est de lancer plusieurs d�mons. Un d�mon est un programme comme un spouleur d'imprimante, un serveur de mail ou un serveur WWW qui se cache en arri�re-plan en attendant d'avoir des choses � faire. Ces programmes sp�ciaux doivent coordonner plusieurs requ�tes qui peuvent entrer en conflit. Il y a des d�mons car il est souvent plus facile d'�crire un programme qui s'ex�cute constamment et qui sait tout des requ�tes, plut�t que d'essayer de s'assurer qu'un troupeau de copies (chacune traitant une requ�te et toutes s'ex�cutant en m�me temps) ne se g�neraient pas mutuellement. La collection particuli�re de d�mons que le syst�me d�marre peut varier, mais inclura presque toujours un spouleur d'imprimante (un d�mon garde-barri�re de votre imprimante).
Une fois que tous les d�mons ont d�marr�, nous sommes dans le niveau
d'ex�cution 2 (run level 2). L'�tape suivante est la pr�paration
pour les utilisateurs. Le noyau d�marre une copie d'un programme
appel� getty pour surveiller votre console (et peut �tre
d'autres copies pour surveiller des ports-s�rie entrants) Ce
programme est celui duquel jaillit le prompt login sur votre
console. Nous sommes maintenant dans le niveau d'ex�cution 3 (run
level 3) et pr�ts pour votre connexion et l'ex�cution de vos
programmes.
Quand vous vous connectez (en donnant un nom et un mot de passe), vous vous
identifiez aupr�s de getty et de l'ordinateur. Il ex�cute
maintenant un programme appel� (assez naturellement) login,
qui r�alise des t�ches ancillaires et d�marre un interpr�teur de
commandes, le shell. (Oui getty et login
pourraient �tre un seul et m�me programme. Ils sont s�par�s pour des
raisons historiques que nous n'expliciterons pas ici.)
Dans la section suivante, nous parlerons de ce qui se passe lorsque vous ex�cutez des programmes � partir du shell.
Le shell normal vous donne le prompt '$' que vous voyez apr�s vous �tre connect� (cependant vous pouvez le modifier et mettre autre chose). Nous ne parlerons pas de la syntaxe du shell et des choses faciles que vous pouvez voir sur votre �cran ici ; alors que nous 'jetterons un oeil' sur ce qu'il se passe du point de vue de l'ordinateur.
Apr�s la phase de boot et avant que vous n'ex�cutiez un programme, vous pouvez penser � votre ordinateur comme �tant un zoo de processus qui attendent qu'il se passe quelque chose. Ils attendent des �v�nements. Un �v�nement, ce peut �tre l'enfoncement d'une touche ou un d�placement de la souris. Ou, si votre machine est connect�e � un r�seau, un �v�nement peut �tre un paquet de donn�es venant de ce r�seau.
Le noyau est un de ces processus. C'en est un sp�cial, car il contr�le le moment o� les autres processus utilisateur peuvent s'ex�cuter, et c'est normalement le seul processus qui acc�de directement au mat�riel de la machine. En fait, les processus utilisateurs font des requ�tes au noyau lorsqu'ils veulent obtenir une entr�e clavier, �crire sur votre �cran, lire ou �crire sur votre disque ou juste autre chose que consommer quelques bits en m�moire. Ces requ�tes sont appel�es appels syst�me.
Normalement toute Entr�e/Sortie passe par le noyau de mani�re � ce qu'il puisse ordonnancer les op�rations et �viter ainsi aux processus de se marcher les uns sur les autres. Quelques processus utilisateur sont autoris�s � contourner le noyau, habituellement en ayant acc�s directement aux ports d'Entr�e/Sortie. Les serveurs X (les programmes qui traitent les requ�tes graphiques des autres programmes sur la plupart des machines Unix) sont des exemples classiques. Mais nous n'avons pas vu de serveur X pour l'instant ; vous �tes au prompt du shell sur une console en mode caract�res.
Le shell est juste un processus utilisateur, et non un processus particuli�rement sp�cial. Il attend vos frappes sur les touches du clavier, �coutant (� travers le noyau) le port d'E/S du clavier. Comme le noyau les voit, il les affiche sur votre �cran et les passe au shell. Le shell essaie de les interpr�ter comme �tant des commandes.
Tapez `ls' suivi de `Enter' afin de lister le contenu d'un r�pertoire. Le shell applique ses r�gles internes pour �valuer la commande que vous voulez ex�cuter dans le fichier `/bin/ls'. Il fait un appel syst�me en demandant au noyau de lancer `/bin/ls' comme un processus fils et donne son acc�s � l'�cran et au clavier � travers le noyau. Le shell se rendort en attendant que 'ls' se termine.
Lorsque /bin/ls est termin�, il dit au noyau qu'il a termin� en effectuant un appel syst�me exit. Le noyau r�veille le shell et lui dit qu'il peut continuer � s'ex�cuter. Le shell affiche un autre prompt et attend une autre ligne en entr�e.
D'autres choses peuvent �tre faites pendant l'ex�cution de `ls', cependant (nous supposerons que la liste du r�pertoire est tr�s longue). Vous pourriez basculer sur une autre console virtuelle, vous connecter, et lancer une jeu de Quake par exemple. Ou bien, supposez que vous �tes connect� � Internet : votre machine peut envoyer ou recevoir des mails pendant que `/bin/ls' s'ex�cute.
Votre clavier est un p�riph�rique tr�s simple ; simple car il g�n�re un petit flux de donn�es tr�s lentement (sur un ordinateur standard). Lorsque vous rel�chez une touche, cet �v�nement est signal� par le c�ble du clavier qui va provoquer une interruption mat�riel.
C'est au syst�me d'exploitation de surveiller de telles interruptions. Pour chaque type possible d'interruption, il y a un handler d'interruption, une partie du syst�me d'exploitation dissimule toutes les donn�es associ�es (comme la valeur touche enfonc�e/touche rel�ch�e) tant qu'elle ne peut �tre trait�e.
Ce que le fait le handler d'interruption disque pour votre clavier est de d�poser la valeur de la touche dans une zone en bas de la m�moire (core). Ainsi elle sera disponible pour l'inspection lorsque le syst�me d'exploitation passera le contr�le � n'importe quel programme suppos� attendre pr�sentement une entr�e clavier.
Des p�riph�riques d'entr�e plus complexes comme les disques travaillent de mani�re similaire. Pr�c�demment nous faisions r�f�rence � un contr�leur de disques utilisant le bus pour signaler qu'une requ�te disque a bien �t� ex�cut�e. Que se passe-t-il si ce disque re�oit une interruption ? Le handler de l'interruption disque copie alors la donn�e trouv�e dans la m�moire, pour une utilisation future par le programme qui en avait fait la demande.
Chaque type d'interruption est associ� � un niveau de priorit�. Les interruptions de plus basse priorit� (comme les �v�nements clavier) sont trait�es apr�s celles de priorit� sup�rieures (comme les tops d'horloge ou les �v�nements disque). Unix a �t� con�u pour traiter prioritairement les types d'�v�nements qui doivent �tre trait�s rapidement afin de conserver une machine sur laquelle les temps de r�ponse sont sont sans �-coup.
Les messages que vous voyez pendant la phase de boot font r�f�rence � des num�ros d'IRQ. Vous devez �tre pr�venus qu'une des causes les plus courantes de mauvaise configuration de votre mat�riel est d'avoir deux p�riph�riques qui essaient d'utiliser la m�me IRQ, sans savoir ce que c'est r�ellement.
La r�ponse est ici. IRQ est l'abbr�viation de "Interrupt ReQuest". Le syst�me d'exploitation a besoin de savoir au d�marrage quel num�ro d'interruption sera utilis� par chaque p�riph�rique, ainsi il peut associer le handler ad�quat pour chacun. Si deux p�riph�riques diff�rents essaient d'utiliser la m�me IRQ, les interruptions seraient quelquefois distribu�es au mauvais handler. Cela est classique au moins au verrouillage du p�riph�rique, et peut parfois d�stabiliser le syst�me d'exploitation, qu'il se "d�sint�gre" ou qu'il se crashe.
En fait, il ne le fait pas. Les ordinateurs ne peuvent traiter qu'une seule t�che (ou processus) � la fois. Mais un ordinateur peut changer de t�che tr�s rapidement, et duper l'esprit humain en lui faisant croire qu'il fait plusieurs choses en m�me temps. C'est ce que l'on appelle le temps partag�.
Une des t�ches du noyau est de g�rer le temps partag�. C'est une partie d�di�e � l'ordonnanceur qui conserve chez lui toutes les informations sur les autres processus (non noyau) de votre environnement. Chaque 1/60 �me de seconde, une horloge avertit le noyau, g�n�rant une interruption horloge. L'ordonnanceur arr�te le processus qui s'ex�cute, le suspend dans l'�tat, et donne le contr�le � un autre processus.
1/60 �me de seconde peut para�tre peu de temps. Mais sur les microprocesseurs actuels c'est assez pour ex�cuter des dizaines de milliers d'instructions machine, ce qui permet d'effectuer beaucoup de choses. M�me si vous avez plusieurs processus, chacun peut accomplir un petit peu sa t�che pendant ses tranches de temps.
En pratique, un programme ne dispose pas de sa tranche de temps enti�re. Si une interruption arrive d'un p�riph�rique d'E/S, le noyau arr�tera en r�alit� la t�che courante, ex�cutera le handler d'interruption et retournera � la t�che courante. Une temp�te d'interruption de haute priorit� peut interdire tout traitement normal ; ce mauvais comportement est appel� d�faite (thrashing) et est difficile � provoquer sur les Unix modernes.
En fait, la vitesse des programmes est tr�s rarement limit�e par le temps machine qu'ils peuvent obtenir (il y a quelques exceptions � cette r�gle, comme la g�n�ration de son ou de graphiques en 3-D. Le plus souvent, les d�lais sont dus � l'attente, par le programme, des donn�es d'un disque ou d'une connexion r�seau.
Un syst�me d'exploitation qui peut supporter de mani�re routini�re plusieurs processus est appel� "multit�che". Les syst�mes d'exploitation de la famille Unix ont �t� con�us d�s le d�but pour le multit�che et sont vraiment bons pour �a -- beaucoup plus efficaces que celui de Windows et MAC OS, pour lesquels le multit�che a �t� introduit a posteriori et qui le traitent plut�t pauvrement. Efficace, multit�che, fiable sont quelques-unes des raisons qui rendent Linux sup�rieur pour le r�seau, les communications et les services WEB.
L'ordonnanceur du noyau fait attention � s�parer les processus dans le temps. Votre syst�me d'exploitation les divise aussi dans l'espace, de telle mani�re que ces processus n'empi�tent pas sur la m�moire de travail des autres. Ces choses que votre syst�me d'exploitation r�alise sont appel�es gestion de la m�moire.
Chaque processus de votre 'troupeau' a besoin de son propre espace m�moire afin de mettre son code et de garder des variables et leur r�sultat. Vous pouvez imaginer cet ensemble constitu� d'un segment de code accessible en lecture uniquement (contenant les instrucions du processus) et un segment de donn�es accessible en �criture (contenant toutes les variables du processus). Le segment de donn�es est v�ritablement propre � chaque processus, mais si deux processus ex�cutent le m�me code, Unix s'arrange automatiquement pour qu'ils partagent le m�me segment de code dans un soucis d'efficacit�.
L'efficacit� est importante car la m�moire est ch�re. Quelquefois, vous ne disposez pas de suffisamment de m�moire pour faire tenir tous les programmes, sp�cialement si vous utilisez un gros programme comme un serveur X-WINDOW. Pour contourner cela, Unix utilise une strat�gie appel�e m�moire virtuelle. Cela n'essaie pas de faire tenir tout le code et les donn�es d'un processus en m�moire. Cependant, il garde seulement un espace de travail ; le reste de l'�tat du processus est laiss� dans un endroit sp�cial sur votre disque : l'espace d'�change (swap space).
Lorsque le processus s'ex�cute, Unix essaie d'anticiper comment l' espace de travail changera, et ne chargera en m�moire que les morceaux dont il a besoin. Faire cela efficacement est compliqu� et d�licat, je n'essaierai pas de le d�crire ici -- mais cela d�pend du fait que le code et les r�f�rences aux donn�es peuvent arriver en blocs, avec chaque nouveau r�f�ren�ant vraisemblablement un proche ou un ancien. Ainsi, si Unix garde le code ou les donn�es fr�quemment (ou r�cemment) utilis�s, vous gagnerez du temps.
Notez que dans le pass�, le "quelquefois" que nous employons deux paragraphes plus haut �tait "souvent" voire "toujours", -- la taille de la m�moire �tait habituellement petite par rapport � la taille des programmes en cours d'ex�cution, de telle mani�re que les �changes entre le disque et la m�moire ("swapping") �taient fr�quents. La m�moire est beaucoup moins ch�re de nos jours et m�me les machines bas de gamme en sont bien dot�es. Sur les machines mono-utilisateur avec 64Mo de m�moire, il est possible de faire tourner X-WINDOW et un m�lange de programmes sans jamais swapper.
M�me dans cette situation joyeuse, la part du syst�me d'exploitation appel�e le gestionnaire de m�moire a un important travail � faire. Il doit �tre s�r que les programmes ne peuvent modifier que leurs segments de m�moire -- ce qui emp�che un code erron� ou malicieux dans un programme de ramasser les donn�es dans un autre. Pour faire cela, il conserve une table des segments de donn�es et de code. La table est mise � jour chaque fois qu'un processus demande de la m�moire ou en lib�re (habituellement plus tard lorsqu'il se termine).
Cette table est utilis�e pour passer des commandes � une partie sp�cialis�e du mat�riel sous-jacent appel�e un UGM (MMU) ou unit� de gestion m�moire (memory management unit). Les processeurs modernes disposent de MMUs int�gr�s. Le MMU a la facult� de mettre des barri�res autour de zones m�moire, ainsi une r�f�rence en "dehors des clous" sera refus�e et g�n�rera une interruption sp�ciale pour �tre trait�e.
Si vous avez d�j� vu le message Unix qui dit "Segmentation fault", "core dumped" ou quelque chose de similaire, c'est exactement ce qu'il se passe ; un programme en cours d'ex�cution a tent� d'acc�der � de la m�moire en dehors de son segment et a provoqu� une interruption fatale. Cela indique un bug dans le code du programme ; le core dump laisse une information en vue d'un diagnostic � l'attention du programmeur afin qu'il puisse trouver la trace de son erreur.
Sur votre disque dur sous Unix, vous voyez un arbre de r�pertoires nomm�s et des fichiers. Normalement vous ne devriez pas � chercher � en savoir plus, mais cela peut s'av�rer utile de savoir ce qu'il y a dessous si vous avez un crash disque et besoin d'essayer de nettoyer des fichiers. Malheureusement il n'y a pas de bon moyen de d�crire l'organisation du disque en partant du niveau fichier et en descendant, c'est pour cela que je le d�crirai en remontant � partir du niveau mat�riel.
La surface de votre disque , sur laquelle il stocke les donn�es est divis�e comme une cible de jeu de fl�chettes -- en pistes circulaires qui sont partag�es en secteurs. Parce que les pistes de l'ext�rieur contiennent plus de surface que celles pr�s de l'axe de rotation, au centre du disque, les pistes externes ont plus de secteurs que celles de l'int�rieur. Chaque secteur (ou bloc disque) a la m�me taille, qui est g�n�ralement de 1Ko (1024 mots de 8 bits). Chaque bloc disque a une adresse unique ou un num�ro de bloc disque.
Unix divise le disque en partitions disque. Chaque partition est une succession de blocs qui est utilis�e ind�pendamment des autres partitions, comme un syst�me de fichiers ou un espace d'�change (swap space). La partition ayant le plus petit num�ro est souvent trait�e sp�cialement, telle la partition de boot dans laquelle vous pouvez mettre un noyau pour booter.
Chaque partition est soit un espace de swap (utilis� pour impl�menter la m�moire virtuelle) soit un syst�me de fichiers pour stocker des fichiers. Les partitions de swap sont trait�es comme une s�quence lin�aire de blocs. Les syst�mes de fichiers d'un autre cot�, ont besoin de relier les noms de fichiers � des s�quences de blocs disque. Parce que les fichiers grossissent, diminuent, et changent tout le temps, les blocs de donn�es d'un fichier ne seront pas une s�quence lin�aire mais pourront �tre dispers�s sur toute la partition (tant que le syst�me d'exploitation pourra trouver un bloc libre).
Dans chaque syst�me de fichiers, la liaison entre les noms et les blocs est r�alis�e gr�ce � une structure appel�e i-node (noeud d'index). Il y en a tout un tas proche de la "base" (num�ro de bloc les plus faibles) du syst�me de fichiers (les tout premiers sont utilis�s pour des besoins d'int�grit� et de label que nous ne d�crirons pas ici). Chaque i-node d�crit un fichier. Les blocs de donn�es des fichiers sont au dessus des i-nodes (conceptuellement).
Chaque i-node contient la liste des num�ros des blocs du fichier (r�ellement c'est une demi-v�rit�, c'est seulement valable pour les petits fichiers, mais le reste de ces d�tails ne sont pas importants ici). Notez que l'i-node ne contient pas le nom du fichier.
Les noms des fichiers r�sident dans les structures de r�pertoires. Une structure de r�pertoire contient juste une table des noms et des num�ros d'i-node associ�s. C'est la raison pour laquelle, sous Unix, un fichier peut avoir plusieurs noms r�els (ou liens forts (hard links)) ; Il y a juste plusieurs entr�es dans un r�pertoire qui pointent vers le m�me i-node.
Dans le cas le plus simple, votre syst�me de fichiers Unix tient sur une seule partition disque. Cependant vous verrez que cette disposition sur des petits syst�mes Unix n'est pas pratique. Typiquement il est r�parti sur plusieurs partitions disque voire sur plusieurs disques physiques. Ainsi par exemple, votre syst�me peut avoir une petite partition o� le noyau r�side, une un peu plus grande pour les utilitaires du syst�me et une beaucoup plus grosse pour les r�pertoires des utilisateurs.
La seule partition � laquelle vous aurez acc�s imm�diatement apr�s le boot est votre partition racine (root partition), qui est (presque toujours) celle � partir de laquelle vous avez boot�. Elle contient le r�pertoire racine du syst�me de fichiers, le noeud le plus haut � partir duquel tout est raccroch�.
Les autres partitions du syst�me doivent �tre attach�es � cette racine afin que votre syst�me de fichiers unique ou multi-partition soit accessible. Au milieu du processus de boot, votre Unix rendra ces partitions 'non root' accessibles. Il devra monter chacune d'elles sur un r�pertoire de la partition racine.
Par exemple, si votre Unix a un r�pertoire appel� '/usr', c'est probablement un point de montage d'une partition qui contient un tas de programmes install�s avec votre Unix mais qui ne sont pas n�cessaires durant la phase initiale de boot.
Maintenant nous pouvons consid�rer le syst�me de fichiers dans une d�marche descendante. Lorsque vous ouvrez un fichier (tel que /home/esr/WWW/ldp/fundamentals.sgml) voici ce qu'il arrive :
Votre noyau d�marre de la racine de votre syst�me de fichiers Unix (dans la partition root). Il cherche un r�pertoire appel� `home'. Habituellement `home' est un point de montage d'une grande partition pour les utilisateurs, il descend � l'int�rieur. Au sommet de la structure du r�pertoire de cette partition utilisateur, il va chercher une entr�e nomm�e `esr' et en extraire le num�ro d'i-node. Il ira � cette i-node, notez que c'est une structure de r�pertoire, et retrouvera `WWW'. En exploitant cet i-node, il ira au sous r�pertoire correspondant et retrouvera `ldp'. Ce qui lui donnera encore un autre i-node r�pertoire. En ouvrant ce dernier, il trouvera un num�ro d'i-node pour `fundamentals.sgml'. Cet i-node n'est pas un r�pertoire mais fournit la liste des blocs associ�s au fichier.
Plus haut, nous avons laiss� entendre que les syst�mes de fichiers �taient fragiles. Maintenant nous savons que pour acc�der � un fichier vous devez parcourir une longue cha�ne arbitraire de r�f�rences � des r�pertoires et � des inodes. A pr�sent, supposons que votre disque dur poss�de une zone d�fectueuse.
Si vous �tes chanceux, il d�truira quelques donn�es d'un fichier. Si vous �tes malchanceux, il va corrompre une structure de r�pertoire ou un num�ro d'inode et laissera un sous arbre entier de votre syst�me dans l'oubli -- ou, pire, cela a donn� une structure corrompue qui pointe par plusieurs chemins au m�me bloc disque ou inode. Une telle corruption peut s'�tendre par des op�rations courantes sur les fichiers qui ne se trouvent pas au point d'origine.
Heureusement, ce genre de d'impr�vu devient de plus en plus rare car les disques sont de plus en plus fiables. Malgr� tout, cela veut dire que votre Unix voudra v�rifier p�riodiquement l'int�grit� du syst�me de fichiers afin de s'assurer que rien ne cloche. Les Unix modernes font une v�rification rapide sur chaque partition au moment du boot, juste avant de les monter. Au bout d'un certain nombre de red�marrages (reboot), la v�rification sera plus approfondie et durera quelques minutes.
Si tout cela vous parait, comme Unix, terriblement complexe et pr�dispos� aux d�faillances, au contraire, c'est rassurant de savoir que ces v�rifications faites au d�marrage de la machine, d�tectent et corrigent les probl�mes courants avant qu'ils ne deviennent r�ellement d�sastreux. D'autres syst�mes d'exploitation ne disposent pas de ces fonctionnalit�s, qui acc�l�rent un petit peu le d�marrage, mais peuvent vous laisser tout 'bousiller' en essayant de r�cup�rer � la main (et en supposant que vous ayez une copie des Utilitaires Norton ou autre � port�e de main...).
Nous avons d�j� �voqu� comment les programmes sont ex�cut�s. Chaque programme en fin de compte doit ex�cuter une succession d'octets qui sont les instructions dans le langage machine de votre ordinateur. Les humains ne pratiquent pas tr�s bien le langage machine ; cela est devenu rare, art obscur m�me parmi les hackers.
La plupart du code du noyau d'Unix except� une petite partie de l'interface avec le mat�riel est de nos jours �crite dans un langage de haut niveau. (Le terme 'haut niveau' est un h�ritage du pass� afin de le distinguer du 'bas-niveau' des langages assembleur, qui sont de maigres "couches" autour du code machine.
Il y plusieurs types diff�rents de langages de haut niveau. Afin de parler d'eux, vous trouverez utile que j'attire votre attention sur le fait que le code source d'un programme (la cr�ation humaine, la version �ditable) est pass� � travers plusieurs types de traductions pour arriver en code machine, que la machine peut effectivement ex�cuter.
Le type le plus classique de langage est un langage compil�. Les langages compil�s sont traduits en fichiers ex�cutables de code machine binaire par un programme sp�cial appel� (assez logiquement) un compilateur. Lorsque le binaire est g�n�r�, vous pouvez l'ex�cuter directement sans regarder � nouveau dans le code source. (La plupart des logiciels d�livr�s sous forme de binaires compil�s sont faits � partir d'un source auquel vous n'avez pas acc�s.)
Les langages compil�s tendent � fournir une excellente performance et ont un acc�s le plus complet au syst�me d'exploitation, mais il difficile de programmer avec.
Le langage C, langage dans lequel chaque Unix est lui-m�me �crit, est de tous le plus important (avec sa variante C++). FORTRAN est un autre langage compil� qui reste utilis� par de nombreux ing�nieurs et scientifiques mais plus vieux et plus primitif. Dans le monde Unix aucun autre langage compil� n'est autant utilis�. En dehors de lui, COBOL est tr�s largement utilis� pour les logiciels de finance et comptabilit�.
Il y a bien d'autres compilateurs de langages, mais la plupart sont en voie d'extinction ou sont strictement des outils de recherche. Si vous �tes un nouveau d�veloppeur Unix qui utilise un langage compil�, il est incontournable que ce soit C ou C++.
Un langage interpr�t� d�pend d'un programme interpr�teur qui lit le code source et traduit � la vol�e en calculs et appels syst�me. Le source doit �tre r�-interpr�t� (et l'interpr�teur pr�sent) � chaque fois que le programme est ex�cut�.
Les langages interpr�t�s tendent � �tre plus lents que les langages compil�s, et limitent souvent les acc�s au syst�me d'exploitation ou au mat�riel sous-jacent. D'un autre c�t�, il est plus facile de programmer et ils tol�rent plus d'erreurs de codage que les langages compil�s.
Quelques utilitaires Unix, incluant le shell et bc(1) et sed(1) et awk(1), sont effectivement des petits langages interpr�t�s. Les BASICs sont g�n�ralement interpr�t�s. Ainsi est Tcl. Historiquement, le langage le plus interpr�t� �tait LISP (une am�lioration �norme sur la plupart de ses successeurs). Aujourd'hui, Perl est tr�s largement utilis� et devient r�solument plus populaire.
Depuis 1990 un type de langage hybride qui utilise la compilation et l'interpr�tation est devenu incroyablement important. Les langages P-code sont comme des langages compil�s dans le sens o� le code est traduit dans une forme binaire compacte qui est celle que vous ex�cutez, mais cette forme n'est pas du code machine. Au lieu de cela, c'est du pseudo-code (ou p-code), qui est g�n�ralement un peu plus simple mais plus puissant qu'un langage machine r�el. Lorsque vous ex�cutez le programme, vous interpr�tez du p-code.
Le p-code peut s'ex�cuter pratiquement aussi rapidement que du binaire compil� (les interpr�teurs de p-code peuvent �tre relativement simples, petits et rapides). Mais les langages p-code peuvent garder la flexibilit� et la puissance d'un bon interpr�teur.
D'importants langages p-code sont Python et Java.
Afin de vous aider � comprendre comment Internet fonctionne, nous verrons ce qui se passe lorsque vous effectuez une op�ration classique -- pointer dans un navigateur ce document � partir du site Web de r�f�rence du Projet de Documentation de Linux (Linux Documentation Project). Ce document est :
http://sunsite.unc.edu/LDP/HOWTO/Fundamentals.html
ce qui veut dire qu'il r�side dans le fichier LDP/HOWTO/Fundamentals.html, sous le r�pertoire export� World Wide Web de la machine sunsite.unc.edu.
La premi�re chose que votre navigateur doit faire est d'�tablir une connexion r�seau avec la machine sur laquelle se trouve le document. Pour faire cela, il doit tout d'abord trouver la localisation r�seau de l'h�te sunsite.unc.edu (h�te est un raccourci pour `machine h�te' ou `h�te r�seau' ; sunsite.unc.edu est un nom d'h�te (hostname) typique). La localisation correspondante est en fait un nombre appel� adresse IP (nous expliquerons la partie `IP' de ce terme plus tard).
Pour faire cela, votre navigateur sollicite un programme nomm� serveur de noms. Le serveur de noms peut r�sider sur votre machine, mais il est plus probable qu'il soit sur une machine de service avec laquelle vous pouvez dialoguer. Lorsque vous abonnez chez un Fournisseur d'Acc�s � Internet (FAI), une partie de la proc�dure d'installation d�crit certainement la mani�re d'indiquer � votre logiciel Internet l'adresse IP du serveur de noms du r�seau du FAI.
Les serveurs de noms sur diff�rentes machines communiquent avec les autres en �changeant et en gardant � jour toutes les informations n�cessaires � la r�solution de noms d'h�te (en les associant � des adresses IP). Votre serveur de noms doit demander � trois ou quatre sites � travers le r�seau afin de r�soudre sunsite.unc.edu, mais cela se d�roule vraiment rapidement (en moins d'une seconde).
Le serveur de noms dira � votre navigateur que l'adresse IP de Sunsite est 152.2.22.81 ; sachant cela, votre machine sera capable d'�changer des bits avec Sunsite directement.
Ce que le navigateur veut faire est d'envoyer une commande au serveur Web sur Sunsite qui a la forme suivante :
GET /LDP/HOWTO/Fundamentals.html HTTP/1.0
Que se passe-t-il alors ? La commande est faite de paquets ; un bloc de bits comme un t�l�gramme est d�coup� en trois choses importantes : l'adresse source (l'IP de votre machine), l'adresse destination (152.2.22.81), et le num�ro de service ou num�ro de port (80, dans ce cas) qui indique que c'est une requ�te World Wide Web.
Alors votre machine envoie le paquet par le fil (de la connexion modem avec votre FAI, ou le r�seau local) jusqu'� ce qu'il rencontre une machine sp�cialis�e appel�e routeur. Le routeur poss�de une carte de l'Internet dans sa m�moire -- pas une compl�te mais une qui d�crit votre voisinage r�seau et sait comment aller aux routeurs pour les autres voisinages sur l'Internet.
Votre paquet peut passer � travers plusieurs routeurs sur le chemin de sa destination. Les routeurs sont adroits. Ils regardent combien de temps prend un accus� r�ception pour recevoir un paquet. Ils utilisent cette information pour aiguiller le trafic sur les liens rapides. Ils l'utilisent pour s'apercevoir que d'autres routeurs (ou un c�ble) sont d�connect�s du r�seau et modifier le chemin si possible en trouvant une autre route.
Il existe une l�gende urbaine qui dit qu'Internet a �t� con�u pour survivre a une guerre nucl�aire. Ce n'est pas vrai, mais la conception d'Internet est extr�mement bonne en ayant une performance fiable bas� sur des couches mat�rielles d'un monde incertain... C'est directement du au fait que son intelligence est distribu�e � travers des milliers de routeurs plut�t qu'� quelques auto-commutateurs massifs (comme le r�seau t�l�phonique). Cela veut dire que les d�faillances tendent � �tre bien localis�es et le r�seau peut les contourner.
Une fois que le paquet est arriv� � destination, la machine utilise le num�ro de service pour le fournir au serveur Web. Le serveur Web peut savoir � qui r�pondre en regardant l'adresse source du paquet. Quand le serveur Web renvoie ce document, il sera coup� en plusieurs paquets. La taille des paquets varie en fonction du m�dia de transmission du r�seau et du type de service.
Pour comprendre comment des transmissions de multiples paquets sont r�alis�es, vous devez savoir que l'Internet utilise actuellement deux protocoles empil�s l'un sur l'autre.
Le plus bas niveau, IP (Internet Protocol), sait comment recevoir des paquets individuels d'une adresse source vers une adresse destination (c'est pourquoi elles sont appel�es adresses IP). Cependant, IP n'est pas fiable ; si un paquet est perdu ou jet�, les machines source et destination ne le sauront jamais. Dans le jargon r�seau, IP est un protocole sans connexion (ou mode non connect�) ; l'exp�diteur envoie juste un paquet au destinataire et n'attend jamais un accus� de r�ception.
Cependant, IP est rapide et peu co�teux. Quelquefois, rapide, peu co�teux et non fiable c'est OK. Lorsque vous jouez en r�seau � Doom ou Quake, chaque balle est repr�sent�e par un paquet IP. Si quelques-unes sont perdues, c'est OK.
Le niveau sup�rieur, TCP (Transmission Control Protocol), fournit la fiabilit�. Quand deux machine n�gocient une connexion TCP (ce qu'elles font en utilisant IP), le destinataire doit envoyer des accus�s de r�ception des paquets qu'il re�oit � l'exp�diteur. Si l'exp�diteur ne re�oit pas un accus� de r�ception pour un paquet apr�s un certain temps, il renvoie ce paquet. De plus, l'exp�diteur donne � chaque paquet TCP un num�ro de s�quence, que le destinataire peut utiliser pour r�-assembler les paquets dans le cas o� il sont arriv�s dans le d�sordre. (Cela peut arriver si les liens r�seau se r�tablissent ou cassent pendant une connexion.)
Les paquets TCP/IP contiennent �galement un checksum pour permettre la d�tection de donn�es alt�r�es par de mauvais liens. Ainsi, du point de vue de quelqu'un utilisant TCP/IP et des serveurs de noms, il ressemble � une voie fiable pour faire passer des flux d'octets entre des paires h�te/num�ro de services. Les gens qui �crivent des protocoles r�seau ne doivent pas se soucier la plupart du temps de la taille des paquets, du r�-assemblage des paquets, de la v�rification d'erreurs, le calcul du checksum et la retransmission qui sont au niveau inf�rieurs.
Maintenant revenons � notre exemple. Les navigateurs et les serveurs Web parlent un protocole d'application qui est au dessus de TCP/IP, en l'utilisant simplement comme une mani�re de passer des cha�nes d'octets dans les deux sens. Ce protocole est appel� HTTP (Hyper-Text Transfer Protocol) et nous en avons d�j� vu une commande -- la commande GET utilis�e ci-dessus.
Lorsque la commande GET arrive au serveur Web de sunsite.unc.edu avec comme num�ro de service 80, elle sera exp�di�e � un d�mon serveur qui �coute le port 80. La plupart des services Internet sont impl�ment�s par des d�mons serveurs qui ne font rien d'autre qu'attendre sur des num�ros de port, r�colter et ex�cuter les commandes entrantes.
Cette conception de l'Internet a une r�gle qui prime sur les autres, c'est que toutes les parties sont le plus simple possible et humainement accessible. HTTP, et ses comp�res (comme le Simple Mail Transfer Protocol, SMTP, qui est utilis� pour transporter du courrier �lectronique entre des machines) utilisent de simples commandes de texte qui se terminent par un retour chariot.
C'est rarement inefficace ; dans certaines circonstances vous pouvez obtenir plus de rapidit� en employant un protocole binaire fortement cod�. Mais l'exp�rience a montr� que le b�n�fice d'avoir des commandes qui sont faciles � d�crire et � comprendre l'emportent sur le gain marginal de l'efficacit� que l'on peut esp�rer au prix de choses compliqu�es et compactes.
Par cons�quent, ce que le d�mon serveur vous renvoie via TCP/IP est aussi du texte. Le d�but de la r�ponse ressemblera � quelque chose comme (quelques en-t�tes ont �t� supprim�s) :
HTTP/1.1 200 OK Date: Sat, 10 Oct 1998 18:43:35 GMT Server: Apache/1.2.6 Red Hat Last-Modified: Thu, 27 Aug 1998 17:55:15 GMT Content-Length: 2982 Content-Type: text/html
Ces en-t�tes seront suivis d'une ligne vide et du texte de la page Web (apr�s que la connexion sera rompue). Votre navigateur affichera simplement cette page. Les en-t�tes indiquent -- en particulier, l'en-t�te Type de Contenu (Content-Type) -- comment les donn�es re�ues sont vraiment du HTML).