Wiki du LAMA (UMR 5127) - Contributions [fr]

MettreAFS

2012-09-14T13:36:24Z

Hatat : /* Passer une machine de NFS vers AFS */

= Passer une machine de NFS vers AFS =

== Kerbériser la machine ==

> sudo apt-get install libpam-krb5 heimdal-clients libpam-afs-session

Dans /etc/krb5.conf :
[libdefaults]
default_realm = LAMA.UNIV-SAVOIE.FR

[realms]
LAMA.UNIV-SAVOIE.FR = {
kdc = lama.univ-savoie.fr
admin_server = lama.univ-savoie.fr
}
[domain_realm]
www.lama.univ-savoie.fr = LAMA.UNIV-SAVOIE.FR
.lama.univ-savoie.fr = LAMA.UNIV-SAVOIE.FR
lama.univ-savoie.fr = LAMA.UNIV-SAVOIE.FR
.univ-savoie.fr = LAMA.UNIV-SAVOIE.FR
univ-savoie.fr = LAMA.UNIV-SAVOIE.FR

== Installer OpenAFS ==

> sudo apt-get install openafs-client openafs-krb5 libpam-afs-session

Peut-être aussi

> sudo apt-get install openafs-modules-dkms

Cellule AFS : lama.univ-savoie.fr
Taille du cache : Christophe veut un cache monstrueux (500 Mo par exemple, dépend de la taille de /var/cache/openafs).

Dans /etc/openafs/CellServDB, virer tout et laisser uniquement :
>lama.univ-savoie.fr
193.48.123.134 # lama.univ-savoie.fr

Puis faire (si vous le voulez des liens pour les homes) :

> sudo rm /home
> sudo rm /home2
> sudo ln -s /afs/lama.univ-savoie.fr/user /home
> sudo ln -s /afs/lama.univ-savoie.fr/user /home2

Enfin, ajouter la ligne

auth optional pam_afs_session.so

à la fin des deux fichiers '''/etc/pam.d/common-auth''' et '''/etc/pam.d/common-session'''.

== Sur MAC OS X 10.7 (marche peut-être avec 10.5 et 10.6) ==

* Le fichier <code>/etc/krb5.conf</code> est à nommer <code>/Library/Preferences/edu.mit.Kerberos</code>
* Il faut installer openAFS depuis la page : [http://www.openafs.org/macos.html http://www.openafs.org/macos.html] et mettre <code>lama.univ-savoie.fr</code> comme cellule par défaut
* le fichier <code>/etc/openafs/CellServDB</code> est alors à placer dans <code>/var/db/openafs/etc/</code>. Remarque : on peut éditer ce ficher depuis le panneaux de préférence d'openAFS ... Sauf que ça semble ne pas marcher (sans doute un pb de permission ?).
* redémarrer le MAC pour être sur de redémarrer openAFS (on doit pouvoir éviter ça)
* dans le panneau de préférence openAFS cocher ''Use aklog'' et ''get credential at login time''
* pour plus de confort créer un lien où bon vous semble pour votre home sur le serveur lama qui est dans <code>/afs/lama.univ-savoie.fr/user/mon_login</code>

== Vérification ==

Logger vous sur la machine et taper '''klist'''.
La réponse doit ressembler à:

Credentials cache: FILE:/tmp/krb5cc_1066_T1K6vd
Principal: raffalli@LAMA.UNIV-SAVOIE.FR

Issued Expires Principal
Aug 14 13:34:19 Aug 15 13:34:19 krbtgt/LAMA.UNIV-SAVOIE.FR@LAMA.UNIV-SAVOIE.FR
Aug 14 13:34:19 Aug 15 13:34:19 afs@LAMA.UNIV-SAVOIE.FR

Les deux dernières lignes vous indique que vous avez un ticket kerberos sur le
royaume du LAMA et un ticket kerberos pour les serveur OpenAFS.

Tapez aussi '''tokens''' avec une réponse attendue qui ressemble à:

Tokens held by the Cache Manager:

User's (AFS ID 1066) tokens for afs@lama.univ-savoie.fr [Expires Aug 15 13:34]
--End of list--

On vois sur l'avant dernière ligne, le jeton afs qui autorise la connection au serveur
et qui a été obtenu auprès du serveur afs en présentant le ticket kerberos afs.

= Possibilités supplémentaires =

== Avoir des droits depuis son compte local ==

Si vous avez un compte local sur votre machine, vous pouvez avoir simultanément les
droits sur votre compte local et sur le compte sur lama.univ-savoie.fr.

Pour cela, une fois loggé sur votre compte local, tapé

> kinit login_sur_lama
> aklog

La première commande sert à obtenir un ticket Kerberos (on
peut vérifir son ticket avec klist) la second commande présente le
ticket pour opbtenir un jeton afs.

Après ça vous devriez avoir les droits sur

/afs/lama.univ-savoie.fr/user/login_sur_lama

== Taille du cache ==

Il n'y a aucune raison que la taille du cache ne soit pas
du même ordre de grandeur que la taille de vos fichiers personnels.

Il faut juste faire attention, le cache est par défaut dans
/var/cache/openafs et il ne faudrait pas qu'un cahce de 20Go
remplisse votre partition /. Donc il faut mettre le cache là où il y a assez de place
(avec un lien symbolique ou en changeant le cache par défaut).

La configuration du cache (taille max et position) est dans

/etc/openafs/cacheinfo

== Renouveler les tickets avec l'écran de veille ==

Dans /etc/pam.d/gnome-screensaver (ou /etc/pam.d/xscreensaver):

auth [success=ok default=1] pam_krb5.so minimum_uid=1000
auth [default=4] pam_afs_session.so nopag
auth [success=3 default=ignore] pam_unix.so nullok_secure try_first_pass
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth optional pam_cap.so

auth optional pam_gnome_keyring.so

= SSh et AFS =

Ce sujet a une page dédiée : [[SshAvecAfs]]

MettreAFS

2012-07-12T16:26:02Z

Hatat : /* Renouveler les tickets avec l'écran de veille */

= Passer une machine de NFS vers AFS =

== Kerbériser la machine ==

# sudo apt-get install libpam-krb5 heimdal-clients

Dans /etc/krb5.conf :
[libdefaults]
default_realm = LAMA.UNIV-SAVOIE.FR

[realms]
LAMA.UNIV-SAVOIE.FR = {
kdc = printers-lama.local.univ-savoie.fr
admin_server = printers-lama.local.univ-savoie.fr
}
[domain_realm]
printers-lama.local.univ-savoie.fr = LAMA.UNIV-SAVOIE.FR
.local.univ-savoie.fr = LAMA.UNIV-SAVOIE.FR
local.univ-savoie.fr = LAMA.UNIV-SAVOIE.FR
lama.univ-savoie.fr = LAMA.UNIV-SAVOIE.FR
.lama.univ-savoie.fr = LAMA.UNIV-SAVOIE.FR
.univ-savoie.fr = LAMA.UNIV-SAVOIE.FR

== Installer OpenAFS ==

# sudo apt-get install openafs-client openafs-krb5 libpam-afs-session

Cellule AFS : lama.univ-savoie.fr
Taille du cache : Christophe veut un cache monstrueux (500 Mo par exemple, dépend de la taille de /var/cache/openafs).

Dans /etc/openafs/CellServDB, virer tout et laisser uniquement :
>lama.univ-savoie.fr
192.168.144.134 # printers-lama.local.univ-savoie.fr

'''Le # n'indique pas un commentaire !'''

# sudo rm /home
# sudo rm /home2
# sudo ln -s /afs/lama.univ-savoie.fr/user /home
# sudo ln -s /afs/lama.univ-savoie.fr/user /home2

== Renouveler les tickets avec l'écran de veille ==

Dans /etc/pam.d/gnome-screensaver :

auth [success=ok default=1] pam_krb5.so minimum_uid=1000
auth [default=4] pam_afs_session.so nopag
auth [success=3 default=ignore] pam_unix.so nullok_secure try_first_pass
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth optional pam_cap.so

auth optional pam_gnome_keyring.so

MettreAFS

2012-07-12T16:20:32Z

Hatat : /* Installer OpenAFS */

MettreAFS

2012-07-12T16:19:15Z

Hatat : /* Installer OpenAFS */

MettreAFS

2012-07-12T16:16:41Z

Hatat : /* Kerbériser la machine */

MettreAFS

2012-07-12T16:11:55Z

Hatat : /* Installer OpenAFS */

MettreAFS

2012-07-12T16:05:16Z

Hatat : /* Kerbériser la machine */

MettreAFS

2012-07-12T16:03:13Z

Hatat : /* Kerbériser la machine */

= Passer une machine de NFS vers AFS =

== Kerbériser la machine ==

# sudo apt-get install libpam-krb5

Dans /etc/krb5.conf :
[libdefaults]
default_realm = LAMA.UNIV-SAVOIE.FR

[realms]
LAMA.UNIV-SAVOIE.FR = {
kdc = printers-lama.local.univ-savoie.fr
admin_server = printers-lama.local.univ-savoie.fr
}

== Installer OpenAFS ==

== Renouveler les tickets avec l'écran de veille ==

MettreAFS

2012-07-12T16:03:01Z

Hatat : /* Kerbériser la machine */

MettreAFS

2012-07-12T15:58:09Z

Hatat :

= Passer une machine de NFS vers AFS =

== Kerbériser la machine ==

== Installer OpenAFS ==

== Renouveler les tickets avec l'écran de veille ==

SshAvecAfs

2012-07-10T14:00:30Z

Hatat : /* Pour chaque serveur SSH */

== Sur le client ==

Dans /etc/ssh/ssh_config, ajouter :
Host *
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Dans /etc/krb5.conf, vérifier que le royaume est bien connu :
[libdefaults]
default_realm = LAMA.UNIV-SAVOIE.FR
forwardable = true
[realms]
LAMA.UNIV-SAVOIE.FR = {
kdc = printers-lama.local.univ-savoie.fr
admin_server = printers-lama.local.univ-savoie.fr
}

== Pour chaque serveur SSH ==

On veut pouvoir se connecter sur d45.lama.univ-savoie.fr depuis une autre machine, grâce au ticket Kerberos que l'on détient dans le royaume LAMA.UNIV-SAVOIE.FR.

On pourrait utiliser les clefs publiques/clefs privées de SSH, mais on a mieux avec Kerberos, car en plus le ticket AFS suit.

=== Sur le serveur du LAMA ===

Le serveur SSH de d45.lama.univ-savoie.fr a besoin d'un principal qui l'identifie dans le royaume. Ce principal c'est host/d45.lama.univ-savoie.fr@LAMA.UNIV-SAVOIE.FR et il faut le créer sur le serveur du LAMA.

# kadmin -l
kadmin> add -r host/d45.lama.univ-savoie.fr@LAMA.UNIV-SAVOIE.FR
Max ticket life [1 week]:
Max renewable life [1 month 1 day]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes []:
kadmin> ext_keytab -k /tmp/d45.keytab host/d45.lama.univ-savoie.fr
kadmin> quit

Ne pas oublier de virer à la fin le fichier /tmp/d45.keytab (c'est une clef secrète) !

=== Sur la machine à kerbériser ===

Il faut activer le support Kerberos sur d45.lama.univ-savoie.fr dans SSH ; dans /etc/ssh/sshd_config :
# Kerberos options
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIStrictAcceptorCheck no # ça c'est super important

Et il faut lui donner son principal secret :

# scp www.lama.univ-savoie.fr:/tmp/d45.keytab /etc/krb5.keytab
# chmod 600 /etc/krb5.keytab

SshAvecAfs

2012-07-10T13:54:02Z

Hatat :

SshAvecAfs

2012-07-10T13:53:06Z

Hatat :

SshAvecAfs

2012-07-10T13:52:45Z

Hatat :

SshAvecAfs

2012-07-10T13:46:34Z

Hatat :

SshAvecAfs

2012-07-10T13:42:19Z

Hatat :

=== Sur le client ===

Dans /etc/ssh/ssh_config, ajouter :
Host *
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Dans /etc/krb5.conf, vérifier que le royaume est bien connu :
[libdefaults]
default_realm = LAMA.UNIV-SAVOIE.FR
forwardable = true
[realms]
LAMA.UNIV-SAVOIE.FR = {
kdc = printers-lama.local.univ-savoie.fr
admin_server = printers-lama.local.univ-savoie.fr
}

Pour chaque serveur SSH :
Dans /etc/ssh/sshd_config :
# Kerberos options
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIStrictAcceptorCheck no # ça c'est super important

Sur le serveur du LAMA :
kadmin -l
addprinc -r host/fqdn.de.la.machine@LAMA.UNIV-SAVOIE.FR

Puis copier le fichier /tmp/keytab.machine vers la machine:/etc/krb5.keytab
chmod 600 /etc/krb5.keytab

SshAvecAfs

2012-07-10T13:40:26Z

Hatat : Instructions pour configurer ssh et sshd avec Kerberos et AFS

Sur le client :

Dans /etc/ssh/ssh_config, ajouter :
Host *
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Dans /etc/krb5.conf, vérifier que le royaume est bien connu :
[libdefaults]
default_realm = LAMA.UNIV-SAVOIE.FR
forwardable = true
[realms]
LAMA.UNIV-SAVOIE.FR = {
kdc = printers-lama.local.univ-savoie.fr
admin_server = printers-lama.local.univ-savoie.fr
}

Pour chaque serveur SSH :
Dans /etc/ssh/sshd_config :
# Kerberos options
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIStrictAcceptorCheck no # ça c'est super important

Sur le serveur du LAMA :
kadmin -l
addprinc -r host/fqdn.de.la.machine@LAMA.UNIV-SAVOIE.FR

Puis copier le fichier /tmp/keytab.machine vers la machine:/etc/krb5.keytab
chmod 600 /etc/krb5.keytab

Documentation

2010-01-26T18:04:44Z

Hatat : /* Problèmes connus sur le réseau LAMA */ Impression qui remarche

==Documentation pour les utilisateurs du réseau LAMA==

[[ Utilisation des imprimantes ]]

[[ Accès au sauvegarde périodique de votre compte ]]

[[ Accès à vos fichiers à partir de Mac OS ]]

[[ Accès à vos fichiers à partir de Windows ]]

[http://www.lama.univ-savoie.fr/wiki/index.php/MUST Accès à la grille de calcul MUST]

[[ Mathrice ]]

[http://www.projet-plume.org/le-projet-description Projet PLUME : promotion du lociel libre]

[[ Synchronisation des comptes : unison ]]

[[ Conversion latex vers html ]]

[[ Machines au LAMA ]]

[[ Utilisation de SVN ]]

[[ Utilisation de la salle 115 ]]

[[ Mise en ligne des calendriers ]]

== Problèmes connus sur le réseau LAMA ==

N'hésitez pas à ajouter quelque chose dans cette section si vous rencontrez un problème. Les administrateurs du réseau reçoivent un mail automatiquement lorsque cette page est modifiée.

- Les options (recto-verso,...) ne sont pas toujours transmises correctement aux imprimantes ...
en cours d'investigation. Si vous n'arrivez pas à faire autrement, un ssh sur www.lama.univ-savoie.fr
et l'utilisation de la commande lpr permet de contourner ce problème.

- <strike>Evince (visualisateur pdf et postscript par défaut sous gnome) ne permet pas d'imprimer sur des serveurs cups distants (le bouton "imprimer" reste grisé). Solution : utiliser kghostview ou un autre visualisateur.</strike> L'impression fonctionne à nouveau depuis les applications Gnome.

==Documentation pour les administrateurs du réseau LAMA==

[[ Ouverture des comptes ]]

[[ Liste des membres du labo sur le site ]]

[[ Installation de ubuntu linux sur les postes clients ]]

[[ Installation de Debian GNU-Linux sur les postes clients ]]

[[ Organisation du serveur web www.lama.univ-savoie.fr ]]

INFO502 : Systèmes d'exploitation

2009-12-11T11:06:53Z

Hatat : /* TP */ Sujet TP3

Ce wiki est un complément de cours pour le cours « info-502 : systèmes d'exploitation ». La participation au wiki est fortement encouragée.

Pour pouvoir modifier les pages, inscrivez-vous (lien en haut à droite) pour obtenir un login et mot de passe. (Choisissez un login du style ''PrenomNom''...)

Je vous conseille d'aller lire [http://meta.wikimedia.org/wiki/Aide:Contenu ce guide] pour vous familiariser avec les wikis.

Exercice : si vous n'en avez pas, créez-vous un compte et essayez de modifier cette page (correction de fautes d'hortographe, rajout de détails, mise en page, ...)

Vous pouvez aussi utiliser la page de discussion pour ... discuter. (Ou poser des questions, faire des commentaires etc.)

----
----
==Auteur du cours==

===Nouvelles===

===Supports===

====TD====

Sujets de TD :
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td1.pdf Ordonnancement],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td2.pdf Gestion de la mémoire],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td3.pdf Systèmes de fichiers].

====TP====

# Découverte de SOS :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp1.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp1.tar.gz code source],
#* [http://www.gnu.org/software/grub/manual/multiboot/multiboot.html Multiboot Specification] : SOS respecte la spécification Multiboot, qui dit comment un système d'exploitation doit être chargé en mémoire par GRUB (ou tout autre chargeur respectant cette spécification).
# Gestion de la mémoire du noyau :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp2.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp2.tar.gz code source],
#* Article [http://sos.enix.org/wiki-fr/upload/SOSDownload/sos-texte-art5.pdf Gestion de la mémoire virtuelle du noyau].
# Ordonnancement :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp3.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp3.tar.gz code source].

==Introduction==

-- ...

==Repères historiques==

Voici quelques évènements clés dans l'histoire des systèmes d'exploitation. Pour plus de détails, ou pour des compléments sur l'histoire de l'informatique, je vous renvoie sur Wikipedia : [http://en.wikipedia.org/wiki/History_of_operating_systems "History of operating systems"] et [http://en.wikipedia.org/wiki/History_of_computing "History of computing"].

Les premiers ordinateurs ne comportaient pas vraiment de système d'exploitation : c'étaient des opérateurs humains qui géraient tout. (C'était juste après la seconde guerre mondiale, l faut savoir que les langages de programmation n'existaient même pas...) La petite histoire (??) raconte qu'à un moment, les processus pour l'ordinateur de l'université de Cambridge étaient accrochés sur une corde à linge et que c'était la couleur des pinces à linges qui donnait la priorité. (??)

Le passage à la notion de système d'exploitation c'est faite graduellement pour répondre à la complexité de plus en plus grande des ordinateurs et aux demandes des utilisateurs.

Les premier systèmes d'exploitation datent probablement de 1956. Ils permettaient simplement d'exécuter un nouveau programme lorsque le précédent était terminé. Les ordinateurs d'IBM de la famille System/360 ont ensuite eu toute une série de systèmes d'exploitation plus ou moins similaires : OS/360, DOS/360 (rien à voir avec MS-DOS), TSS/360... C'est à cette époque qu'est apparu la notion de multiprogrammation (possibilité d'avoir plusieurs processus entrelacés.)
C'est également au début des années 60 qu'on a commencé à voir des systèmes avec temps partagé : plusieurs utilisateurs pouvaient utiliser un ordinateur. Le système Multics a été, à ce niveau comme à d'autres, assez révolutionnaire. Multics a été utilisé jusqu'en 2000 !

Multics n'était par contre pas approprié pour les mini-ordinateurs où le nombre d'utilisateur est relativement restreint. En 1969, Ken Thomson
a développé une variante simplifié de Multix : Unix...

Ce n'est qu'un peu plus tard (1979) que la première version de DOS (86-DOS ou QDOS) apparaît. 86-DOS sera racheté par Microsoft un 1980...

'''Liens et compléments :'''
* [http://en.wikipedia.org/wiki/Timeline_of_operating_systems Timeline of operating systems]
* généalogie des systèmes Unix : [http://www.levenez.com/unix/ Unix History]
* généalogie de Windows : [http://www.levenez.com/windows/ Windows History]
* généalogie des systèmes non-Unix : [http://www.oshistory.net/metadot/index.pl?id=2165 timeline of non-Unix operating systems]

==Vue d'ensemble==

Ce cours reste assez généraliste et essaie de regarder les principales fonction d'un système d'exploitation. Les systèmes de type Unix (Linux) sera un exemple privilégié. À cause de leur complexité intrinsèque, les évolutions modernes (architectures multicoeur ou multiprocesseur, ...) seront en partie ignorée dans un premier temps.

Les problèmes fins de communication entres processus ne seront que très peu abordés, car ils font l'objet d'un cours séparé (info604) pour la filière info.

Nous allons suivre l'ordre classique consistant à regarder :
# les processus
# la mémoire
# les entrées / sorties

La fin du cours dépendra du temps restant...

===Les processus===

Un processus est simplement un programme « en exécution ». À tout instant, un ordinateur de bureau contemporain contient de nombreux processus qui doivent partager le (les) processeur(s) pour donner l'impression qu'ils s'exécutent « en même temps ». Un des rôles du système d'exploitation consiste à décider dans quel ordre les processus vont effectivement pouvoir utiliser le processus.

===La mémoire===

La mémoire est, comme le processeur, une ressource partagée par les différents processus. Il faut donc gérer la quantité de mémoire allouée et utilisée pour que les processus n'aient pas à s'occuper de ceci. Un des concepts fondamentaux est celui de mémoire virtuelle. Ceci permet d'offrir un espace mémoire pour chacun des processus de manière transparente.

===Les entrées / sorties===

Un ordinateur n'est pas (plus) un système indépendant du reste du monde : il interagit avec l'extérieur à travers des périphériques d'entrées/sorties (clavier / écran / souris / ...). La gestion de ces périphériques pose un ensemble de problèmes que nous aborderons brièvement...

===...===

Une fois ces notions vues, nous regarderons peut-être les problèmes de sécurité, de multimédia ou des architectures multiprocesseurs.

==Préliminaires==

===Quoi ?===

Les ordinateurs, ou plus simplement les micro contrôleurs sont des circuits électroniques avec une puce « processeur ». Le développement d'applications n'est pas facile si on se place au niveau électronique et que l'on parle directement au CPU. Pour faciliter la vie des programmeurs, plusieurs couches d'abstraction sont nécessaires. La première se place au niveau matériel et s'occupe directement des problèmes électroniques ou de très bas niveau. Il s'agit du ''firmware''. Il répond par exemple aux questions comme :
* qu'elle est l'amplitude des signaux envoyés par l'horloge ?
* est-ce que l'UC possède un pipeline ?
* ...
Un firmware est donc forcement très lié au matériel sur lequel il tourne.

La couche suivante est le système d'exploitation à proprement parler. Dans le cas que vous connaissez le mieux (ordinateur personnel), le système d'exploitation fournit une interface pour :
* exécuter un programme
* exécuter plusieurs programmes « en même temps »
* gérer les ressources (temps processeur, mémoire disponible, entrées / sorties)
* les opérations sur les fichiers
* offrir des garanties de sécurité

===Où ?===

On trouve des systèmes d'exploitation partout :

* dans les ordinateurs personnels (Linux, BSD, MacOS, Solaris, Windows, ChromeOS (?))
* dans les PDA (PalmOS, ...)
* dans les téléphones portables (Android, OpenMoko,Symbian,)
* console de jeux
* lecteur MP3 (Rockbox, ...)
* les microcontroleurs « avancés »

===Comment ?===

====Langage de programmation====

Le système d'exploitation se situe entre le firmware (très bas niveau) et l'utilisateur. La nécessité d'accéder à ces ressources de très bas niveau implique que les langages de haut niveaux (Java, Ada, Python, ...) ne sont pas du tout adaptés à l'écriture des systèmes d'exploitation.
Le langage le plus utilisé reste à ce jours le langage C : Linux, BSD, MacOS, Windows, ... sont tous écrits pour leur plus grande partie en C.

Vous avez normalement un cours de C en parallèle, et les TPs utiliseront le langage C. (La référence sur le langage C reste à mon goût le livre de Kernighan et Ritchie : « the C Programming language ». (Disponible en francais à la BU sous le titre « Le langage C : norme Ansi ».) Il existe de nombreux autres livres / documents sur la programmation C comme le [http://www-clips.imag.fr/commun/bernard.cassagne/Introduction_ANSI_C.html polycopié de Bernard Cassagne « introduction au langage C »].

Les premiers systèmes d'exploitation étaient écrits directement en langage machine, ou bien en langage d'assembleur ; et les systèmes actuels comportent encore quelques parties de très bas niveau en langage d'assemblage...

====Notion d'appel système, norme POSIX====

La programmation de haut niveau en C est assez différente de la programmation système. De nombreuses fonctions C utilisent en fait des « appels système », c'est à dire des appels de fonctionnalités propres du système d'exploitation. Les appels système typiques sont :
* les fonctions relatives aux fichiers (création, suppression, modification...)
* les fonctions relatives à la gestion de la mémoire
* les fonctions relatives aux processus (<tt>fork</tt>)
* ...

De nombreux système d'exploitation proposent une interface [http://en.wikipedia.org/wiki/Posix POSIX] (« '''P'''ortable '''O'''perating '''S'''ystem '''I'''nterface for Uni'''x''' »). Cette norme définit entre autres un ensemble de fonctions pour utiliser les appels systèmes.
Le nombre de ces fonctions est relativement faible : une centaine ; et chacune correspond en gros à un appel système. Certaines de ces fonctions ne sont pas définies directement dans le système d'exploitation, mais dans des librairies. Pour Linux, il s'agit en général de la librairie Glibc (GNU C Library).

Par exemple, la fonction <tt>open</tt> (qui permet d'ouvrir un fichier) correspond exactement à un appel système ; alors que la fonction <tt>malloc</tt> (qui permet d'allouer dynamiquement de la mémoire dans le tas) peut générer plusieurs appels système (<tt>brk</tt> et <tt>sbrk</tt>).

Pour visualiser les appels systèmes effectués par un programme sous Linux, vous pouvez utilisez l'utilitaire <tt>strace</tt> ou <tt>ltrace</tt>. Par exemple, dans le shell :
$ strace -e trace=file ls -l 2> trace
permet de récupérer tous les appels systèmes relatifs aux fichiers lors de l'appel à <tt>ls -l</tt>. La liste des appels système est redirigée dans le fichier <tt>trace</tt> qui contiendra par exemple des lignes telles que
lstat64("Desktop", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lgetxattr("Desktop", "security.selinux", 0x8cc08e0, 255) = -1 ENODATA (No data available)
dénotant ainsi un appel aux appels système <tt>lstat64</tt> et <tt>lgetxattr</tt>...

Les principaux systèmes compatibles POSIX sont :
* Linux
* BSD (et variantes)
* Mac OS X
* Solaris

De nombreux appels systèmes sont disponibles directement (sans avoir besoin d'écrire un programme C) à travers le shell. Exécuté dans un terminal, le shell permet, en première approximation, de passer directement des commandes au système d'exploitation. (La norme POSIX définit également un ensemble de fonctions du shell. Il est donc relativement aisé de changer de système d'exploitation tant qu'on reste dans les systèmes compatibles POSIX.)

Windows d'un autre côté utilise l'interface Win32 API, qui définit plusieurs milliers de fonctions. La plupart de ces fonctions peuvent utiliser plusieurs appels système...

Les systèmes d'exploitation qui utilisent l'API Win32 sont :
* Windows, depuis Windows95.

Il est possible d'installer un environnement compatible POSIX sur une machine Windows grâce à Cygwin. (C'est d'ailleurs fortement conseillé si vous ne voulez pas installer une version de Linux ou BSD sur votre ordinateur personnel...)

====Mode noyau / mode utilisateur====

La partie fondamentale du système d'exploitation est le ''noyau'' (''kernel'' en anglais). C'est la couche de plus bas niveau.

Les fonctionnalités de très bas niveau offertes par le noyau peuvent facilement planter l'ordinateur. Il faut donc une politique de restriction pour que tous les programmes ne puissent y accéder dans leur totalité. On parle de
* mode noyau
* mode utilisateur

Dans le mode utilisateur, on ne peut accéder à ces fonctionnalités qu'a travers les appels systèmes ; dans le mode noyau, on peut tout faire... Bien entendu, un appel système doit passer momentanément en mode noyau pour pouvoir exécuter les commandes pertinentes, puis il repasse automatiquement en mode utilisateur.

La définition d'un appel système pourrait donc être « fonctionnalité atomique nécessitant un passage en mode noyau ».

====Noyau, noyau monolithique, micro-noyau====

La partie principale du système d'exploitation. C'est lui qui gère les ressources, les entrées / sorties, la communication entre processus, ... Les deux architectures principales pour un noyau sont :
* noyau monolithique
* micro-noyau
La plupart des systèmes actuels sont basés sur un noyau monolithique (Linux, BSD, Mac OS X, Solaris, Windows).

Les noyaux monolithiques sont parfois décrits comme « sans vraie structure » : une grosse soupe où cohabitent toutes les fonctionnalités du système d'exploitation. L'idée d'avoir un système unique qui gère tout est effectivement peu attirante et peut poser quelques problèmes de génie logiciel...
Un noyau monolithique est donc la couche entre le matériel et les programmes utilisateurs. Pour éviter de compiler des noyaux énormes, les noyaux monolithiques actuels utilisent en plus la notion de ''module''. Ce sont des morceaux du noyau qu'on peut charger ou décharger au besoin. Si l'interface est connue, ces modules peuvent éventuellement être en binaire, ce qui permet d'utiliser des modules propriétaires avec un noyau libre.
Sous Linux, la commande
$ lsmod
permet d'obtenir la liste des modules chargés dans le noyau.

Les micro-noyaux d'un autre coté sont basés sur la remarque que seule une toute petite partie du noyau accède effectivement au matériel. Seule cette petite partie nécessite donc des privilèges et effectue des appels système. Le reste du système d'exploitation peut être programmé en mode utilisateur, « au dessus » de cette partie. Par exemple, le micro noyau offrira la possibilité de charger un nouveau processus, mais l'ordonnanceur (qui choisit quel processus devra être chargé) ne fera pas partie du micro-noyau. On parle parfois de ''services'' / ''serveurs'' au dessus du micro-noyau.
Ceci permet d'avoir un noyau bas niveau beaucoup plus petit. Bien que ceci soit une bonne idée, et que les micro-noyaux puissent fournir de meilleurs garanties de sécurité, peu de noyaux sont effectivement des micro-noyaux. Un des problèmes est qu'un tel micro-noyau est un peu plus lent que ses cousins monolithiques. La raison principale est que dans le cas d'un micro-noyau, un appel système nécessite en fait des communications inter-processus.
Andrew Tanenbaum est un fervent défenseur des micro-noyaux.

Une autre architecture possible est d'utiliser des couches successives, chacune avec des privilèges réduits. Le système Multics avait cette architecture.
Par exemple, dans le système THE (1965), les couches étaient les suivantes :
# noyau bas niveau, multiprogrammation
# allocation de la mémoire pour les processus
# IPC (communication inter processus)
# entrées / sorties (buffer, etc.)
# programmes utilisateurs (compilation, exécution, ...)
# utilisateur (Dijkstra a annoté la description de cette couche par ''« not implemented by us »'')

Une dernière catégorie de noyau est la catégorie des machines virtuelles. Ces noyaux sont un peu à part, car il s'agit d'émuler un système d'exploitation ou du matériel particulier à l'intérieur d'un autre système d'exploitation ou matériel. Le mode noyau de la machine virtuelle est en fait dans le mode utilisateur du noyau original...

==Les processus==

===Introduction===

Allez hop commençons par une petite définition du type wikipédia :

Un processus (en anglais, process), en informatique, est défini par :
* un ensemble d'instructions à exécuter (un programme) ;
* un espace mémoire pour les données de travail ;
* éventuellement, d'autres ressources, comme des descripteurs de fichiers, des ports réseau, etc.

Un ordinateur équipé d'un système d'exploitation à temps partagé est capable d'exécuter plusieurs processus de façon « quasi- simultanée ». Par analogie avec les télécommunications, on nomme multiplexage (A. Tanenbaum parle de ''multiprogrammation'') ce procédé. S'il y a plusieurs processeurs, le système essaie de répartir les processus de manière équitable sur les processeurs disponibles.

Le processus doit être imaginé comme quelque chose qui prend du temps, donc qui a un début et (parfois) une fin. De nombreux processus ne se terminent normalement jamais : système d'exploitation, serveurs web, serveurs mail, ... D'autres processus plus légers qui ne se terminent pas sont les ''daemon'' (acronyme ''a posteriori'' de "disk and execution monitor") du monde Unix.

Certains processus sont démarrés très tôt lors de la séquence de boot. Le système d'exploitation est un tel processus. Sinon, les processus sont normalement démarrés grâce à un appel système à partir d'un autre processus. L'utilisateur peut par exemple demander explicitement un nouveau processus (sous POSIX, grâce à un <tt>fork</tt> puis <tt>exec</tt>) ; mais la plupart du temps, il le fera à travers une application, par exemple en double-cliquant sur l'icône d'un programme dans l'explorateur de fichiers.

Le système d'exploitation est chargé d'allouer les ressources (mémoires, temps processeur, entrées/sorties) nécessaires aux processus et d'assurer que le fonctionnement d'un processus n'interfère pas avec celui des autres (isolation).

Pas sûr d'avoir tout compris ? Ce n'est pas grave, essayons autrement.
:'''Définition :''' un processus est un programme en train de s'exécuter.
Cette définition implique en particulier que un programme (navigateur Firefox par exemple) peut correspondre à
* zéro processus si on ne l'a pas lancé,
* un processus si on l'a lancé,
* plusieurs processus si on l'a lancé plusieurs fois.
(''Remarque :'' pour un programme comme Firefox, il y a fort à parier que l'exécution d'une seule instance de Firefox génère de multiples sous-processus...)

Que se passe-t-il quand je démarre une application?

:L'ordinateur à une nouvelle tâche à accomplir, les instructions correspondantes sont donc envoyées au processeur. Comme il a plusieurs choses à faire le choix des instructions à exécuter n'est pas forcement simple. Il faut faire en sorte de partager le processeur entre les différentes tâches de manière équitable : c'est la fameuse gestion des processus.
:Ceci permet de réaliser plusieurs activités en ~même temps~. Grâce à la gestion des processus on peut regarder un film (obtenu par des moyens tout à fait légaux cela va de soit), tout en jouant à la dame de pique.
:(et dire que certain(e)s affirment que l'homme est mono tâche)

Plusieurs processus indépendants peuvent être ''actifs'' en même temps, mais sauf si l'ordinateur possède suffisamment de processeurs, on ne peut pas les exécuter simultanément. L'impression que plusieurs programmes s'exécutent ''en même temps'' vient simplement du fait que le processeur alterne rapidement entre eux.
Comme le temps d'exécution d'une instruction par le processeur est très court, de l'ordre de la nano-seconde, le processeur peut réaliser plusieurs centaines de millions d'instructions par seconde. Ainsi, une tranche de temps de quelques fractions de seconde, partagée entre plusieurs processus, donne à l'échelle macroscopique l'illusion de la simultanéité.

'''En résumé :''' un système d'exploitation doit la plupart du temps traiter plusieurs tâches en même temps, et comme il n'a, en général, qu'un seul processeur, il devra contourner ce problème grâce à un pseudo-parallélisme. Il traite une tâche à la fois, s'interrompt et passe à la suivante. La commutation de tâches étant très rapide, il donne l'illusion d'effectuer un traitement simultané.

===La table des processus===

L'information sur les processus est conservé par le système dans une structure de données appelée ''table des processus''. Cette table contient toutes les informations nécessaires à la gestion des processus :
* état du processus
* PID
* droits
* répertoire de travail
* pointeur vers la pile
* priorités
* ...

Sous Linux, on peut accéder à ces informations à travers le système de fichiers virtuel "Procfs". Il suffit d'aller dans le répertoire <tt>/proc/</tt>.

===Création d'un processus===

Pour les système POSIX, la création d'un processus est très simple : on utilise la fonction <tt>fork()</tt>. En C, le prototype de la fonction se trouve dans le fichier d'entêtes <tt>unistd.h</tt>.

Cette fonction prend 0 argument et permet de faire la chose suivante : elle crée un nouveau processus qui est une copie conforme du processus appelant. La seule différence visible entre l'ancien et le nouveau processus est que les processus ont un numéro (PID) différent. Pour le processus appelant, il peut obtenir le PID du nouveau processus en regardant la valeur de retour de <tt>fork</tt>. Pour le nouveau processus, cette valeur vaudra 0, et il devra utiliser la fonction <tt>getpid()</tt> pour obtenir son numéro.

Le processus appelant est appelé le ''père'' alors que le nouveau processus est appelé le ''fils''.

Notez que l'espace mémoire du processus est dupliqué plutôt que partagé. Ceci veut dire que les processus ne peuvent pas communiquer en utilisant leur variables... Par contre, les descripteurs de fichiers du fils sont hérités directement de ceux du père ; ils peuvent donc essayer de communiquer en passant par ces fichiers. (Mais cela pose de nombreux problèmes de synchronisation.)

Voici par exemple un petit programme C qui lance un processus fils:
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {

int pid ;
int pid_fils ;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
} else {
printf(" >> Je suis le fils.\n");
}

return(0);

}
Après compilation, voici un exemple d'exécution du programme résultant :
$ ./pere_fils
> Le processus 8248 démarre...
>> Je suis le fils.
>> Je suis le père (pid du fils = 8249).

Voici un autre exemple d'exécution :
$ ./pere_fils
> Le processus 8269 démarre...
>> Je suis le père (pid du fils = 8270).
>> Je suis le fils.

Notez que les numéros sont différents, et que l'ordre d'affichage n'est pas le même. Cela vient de l'ordonnancement des deux processus qui peut différer.

La technique consistant à faire
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
...
}
montre que malgré le fait que les processus soient identiques à l'origine, on peut faire beaucoup de chose.

:'''Remarque :''' <tt>fork()</tt> n'est pas directement un appel système, mais une fonction qui utilise l'appel système <tt>clone()</tt>. Cet appel système ne fait pas partie de la norme POSIX...

La deuxième technique utilisée dans les systèmes POSIX consiste à utiliser <tt>fork()</tt> pour dupliquer le processus, puis à complètement remplacer le fils par un nouveau processus. La fonction correspondante est la fonction <tt>execv</tt> :
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
execv("/usr/bin/...", argv);
...
}
La fonction <tt>execv</tt> prend 2 arguments : une chaîne contenant le chemin d'accès à un programme, et un tableau d'arguments à donner au programme. (C'est un peu plus compliqué que ça : le premier élément du tableau est le nom du programme, et le tableau doit se terminer par un pointeur NULL.)

Une dernière fonction importante est la fonction <tt>wait(pid)</tt> qui permet à un processus d'attendre l'arrêt du processus <tt>pid</tt>.

-- ...

L'API WIN32 possède de nombreuses fonctions avec des fonctionnalités similaires. Par exemple, la fonction [http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx <tt>CreateProcess</tt>] permet de créer un nouveau processus (comme un <tt>fork</tt> suivi d'un <tt>exec</tt>), mais elle nécessite ... 10 arguments !

----

Un autre moyen de créer des processus est d'utiliser des 'processus légers' appelés Thread. Ces processus légers partage seulement une partie de la mémoire, ce qui en pratique est plus rapide pour simuler un parallélisme. On passe alors par une autre fonction. Sous GNU/Linux, lors de l'écriture d'un programme écrit en C il faut utiliser la bibliothèque pthread.h et lors de la compilation, faire un lien vers celle ci, en utilisant le paramètre -lpthread.

====Arborescence des processus dans les systèmes POSIX====

Nous avons vu que la fonction <tt>fork()</tt> permet de créer un processus fils. Le père connaît le PID de son fils : il lui est donné par la fonction <tt>fork()</tt>. Comme le fils peut lui même créer des processus fils, on obtient rapidement une arborescence de processus.

Vous pouvez visualiser cette arborescence à partir d'un terminal avec la commande <tt>pstree</tt> (l'option <tt>-p</tt> permet de demander l'affichage des PID)
$ pstree -p
init(1)─┬─acpid(25425)
├─atd(14365)
├─console-kit-dae(3632)─┬─{console-kit-dae}(3633)
│ ├─{console-kit-dae}(3641)
...
├─cron(14315)
├─dbus-daemon(15590)
├─dbus-daemon(3511)
...
├─getty(4095)
├─getty(4096)
├─getty(4097)
├─getty(4098)
├─getty(4099)
├─gpm(3528)
...
├─kded4(15769)
├─kdeinit4(15766)───klauncher(15767)
├─kdm(15564)─┬─Xorg(15566)
│ └─kdm(15573)───sh(15608)─┬─conky(15751)
│ ├─fluxbox(15703)───firefox-bin(6063)─┬─{firefox-bin}(6064)
│ │ ├─{firefox-bin}(6065)
...
│ ├─ssh-agent(15698)
│ ├─unclutter(15742)
│ ├─wicd-client(15749)
│ └─xscreensaver(15683)
...
├─rsyslogd(6850)─┬─{rsyslogd}(6140)
│ └─{rsyslogd}(6141)
├─screen(4427)─┬─bash(4428)───pstree(9307)
│ ├─bash(4429)───man(7952)───pager(7965)
│ ├─bash(4430)───vi(30568)
│ ├─bash(18395)───vi(28512)
│ └─mutt(8763)
...

Le processus <tt>init</tt> est l'ancêtre de tout les processus, il a toujours 1 comme PID.

'''Remarque :''' sous Windows, les processus ne sont pas organisé en arborescence...

====Mort d'un processus dans un système POSIX====

Un processus peut se terminer pour plusieurs raisons :
* volontairement, grâce à la fonction <tt>exit()</tt> (POSIX) ou <tt>ExitProcess()</tt> (Windows),
* à cause d'une erreur,
* en recevant un signal d'un autre processus, grâce à la fonction <tt>kill()</tt> (POSIX) ou <tt>TerminateProcess()</tt> (Windows).

Lorsqu'un processus se termine, plusieurs choix sont possibles :
* que fait-on de ses fils ?
* que fait-on de son père ?

Linux fait la chose suivante : quand un processus s'arrête,
* tous ces fils s'arrêtent,
* son père reçoit un signal le prévenant que son fils vient de mourir.

Pour que le père puisse recevoir le signal correspondant, il faut qu'il utilise la fonction <tt>wait()</tt> ou <tt>waitpid()</tt>. Tant que le parent existe et qu'il n'a pas reçu le signal disant qu'un de ces fils est mort, le processus fils n'est pas entièrement supprimé : il devient un ''zombie''. (Il n'occupe plus vraiment de place en mémoire, mais le système garde juste suffisamment d'information pour pouvoir prévenir le père si celui ci demande l'état du fils.)

'''Remarque :''' les processus Windows ne sont pas organisés sous forme d'arborescence. Chaque processus peut surveiller l'état d'un autre processus, s'il connaît son PID. Il n'y a donc pas de notion de processus ''zombie'' sous Windows.

Voici un petit programme C qui crée un processus fils, ne fait rien pendant 20 secondes, puis demande l'état de son fils :
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
int pid ;
int pid_fils ;
int w;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
printf(" >> Je suis le père et j'attends un peu.\n");
sleep(20);
printf(" >> Je suis le père et je demande l'état de mon fils.\n");
wait(&w);
printf(" >> Mon fils est mort (signal %i).\n", w);
while(1) sleep(1);
} else {
printf(" >> Je suis le fils.\n");
while (1) sleep(1);
exit(0);
}
return(0);
}
Si on tue le processus fils pendant que le père ne fait rien, le processus fils devient un zombie. Dès que le père fait le <tt>wait</tt>, il reçoit la valeur du signal qui a terminé le processus et le zombie disparaît.

Si on ne tue pas le processus fils, le père n'exécutera jamais le <tt>printf(" >> Mon fils est mort...);</tt>.

'''Remarque :''' dans un système POSIX, lorsqu'un processus meurt, ses fils deviennent ''orphelins''. Il continuent leur exécution mais sont adopté par <tt>init</tt> (PID : 1). Dans certains cas lorsque le processus est arrêté, il envoie explicitement un signal <tt>SIGTERM</tt> pour tuer ses processus fils. C'est par exemple ce qui arrive lorsqu'on lance des application à partir d'un terminal et que l'on quitte le terminal en question...

===États d'un processus===

On peut imaginer un SE dans lequel les processus pourraient être dans trois états :
* en cours d'exécution,
*bloqué : il attend un événement extérieur pour pouvoir continuer (par exemple une ressource; lorsque la ressource est disponible, il passe à l'état "prêt")
*prêt : suspendu provisoirement pour permettre l'exécution d'un autre processus.

Dans un système avec un unique processeur, au plus un processus peut se trouver dans l'état ''en cours d'exécution''. Par contre, il peut y avoir de nombreux processus dans l'état ''bloqué'' ou dans l'état ''prêt''.

Un processus peut passer d'un état à l'autre :
# de ''en exécution'' à ''bloqué'' lorsqu'une ressource n'est pas disponible (entrées / sortie par exemple),
# de ''bloqué'' à ''prêt'' si la ressource ayant provoqué le blocage devient disponible,
# de ''en exécution'' à ''prêt'' si le système décide de suspendre l'exécution du processus,
# de ''prêt'' à ''en exécution'' si le système décide de lancer l'exécution du processus.

On peut résumer ceci par le graphe de transitions suivant :

[[Image:Diagrammedétatdunprocessus.png]]

Les transition manquantes ne sont pas possible directement mais doivent passer par des transition intermédiaires.

On peut ajouter 2 états :
* ''nouveau'' pour un processus qui vient d'être créé,
* ''terminé'' pour un processus qui vient de se terminé.

Dans les systèmes type ''ordinateur de bureau'', le passage de ''nouveau'' à ''prêt'' est automatique mais dans des systèmes temps réel, un processus peut parfois attendre dans cet état.

L'état ''terminé'' est en général passager. Par exemple, lorsqu'un processus terminé est un zombie, le processus n'est conservé que dans la table des processus. La mémoire utilisé par le processus est libérée. La question de savoir si ceci est véritablement un état du processus est donc essentiellement une question de vocabulaire.

:exercice : ajouter les états ''nouveau'' et ''terminé'' et les transitions correspondantes au graphe précédent. Identifiez des situations provoquant les transitions possibles entre états.

===Ordonnancement des processus===

Nous avons vu qu'il pouvait y avoir de nombreux processus dans la table de processus (environ 150 sur mon ordinateur en ce moment même). Parmi ces processus, un seul (sur une machine à un processeur) peut se trouver dans l'état ''en exécution''. C'est au système d'exploitation de décider qui, à un moment donnée, doit se trouver dans cet état. La partie du système faisant ceci s'appelle ''ordonnanceur'' (ou ''scheduler'' en anglais).
En utilisant le contenu de la table des processus et éventuellement d'autres information, ordonnanceur doit donc gérer les transition entre états de tous les processus, et envoyer l'information nécessaire aux composants adéquat du noyau.

Comme d'habitude, l'ordonnanceur doit faire des compromis entre :
* la vitesse,
* l'utilisation de la mémoire,
* l'optimalité de la solution proposée.

'''Remarque : ''' l'ordonnanceur est lui même un processus (ou un morceau de processus dans le cas des noyaux monolithiques).

====Ordonnancement non préemptif====

'''FIFO.'''
L'algorithme d'ordonnancement le plus facile est probablement celui de type ''FIFO'' : premier arrivé, premier servi. Autrement dit, on préempte premier processus arrivé, et on l'exécute jusqu'à la fin. La seul structure de donnée est donc simplement une ''file''.

'''Plus court temps d'exécution.'''
Dans certain cas, on peut prévoir a l'avance le temps processeur dont aura besoin un processus pour s'exécuter. On peut alors choisir le processus le plus court et l'exécuter en premier. Ceci a en général tendance à diminuer le temps d'attente moyen d'un processus ; mais si des processus courts sont crées régulièrement, on peut assister à une ''famine'' : un processus peut ne jamais s'exécuter.

:exercice : trouver une suite de processus qui provoque une famine.

Ces deux exemples sont acceptables pour un ''traitement par lots'' (batch) par exemple pour des calculs numériques. Ils ne sont par contre pas du tout adaptés pour un ordinateur personnel ou un système temps réels. (Pas de ''multiprogrammation''.)

====Ordonnancement préemptif====

Pour pouvoir donner l'illusion de simultanéité, les processus sont en général exécutés par tranches de temps spécifiées à l'avance (''time slice'' en anglais). Au bout de ce temps, le noyau reçoit une interruption et examine les processus. Il peut décider de continuer le processus courant, ou bien le remplacer par un autre processus. on parle de préemption.

Windows 3.1 ou MacOS 9 étaient des systèmes ''collaboratifs'' car les processus devaient explicitement laisser la main aux autres processus. Tous les systèmes d'exploitation modernes sont maintenant préemptifs. On parle maintenant de système préemptif lorsque la préemption peut s'effectuer même sur des processus en mode noyau.
On parle parfois de noyau préemptible lorsque que les opérations en mode noyau sont elle même préemptibles.

'''Tourniquet.'''
L'algorithme le plus simple est probablement celui du tourniquet (''round Robin'' en anglais). C'est une variante de l'algorithme FIFO vu plus haut, mais qui préempte le processus courant au bout d'un moment. Si ce processus est encore en exécution, on le remet à la fin de la file des processus.

Le temps imparti à chaque processus ne doit pas être trop court (sinon, le changement de contexte prend trop de temps par rapport à l'exécution des processus) ni trop long (sinon, on perd l'illusion de parallélisme, et un processus bloqué risque d'occuper le processeur pendant trop longtemps).

Voici ce qu'on peut trouver dans le livre "Understanding the Linux kernel" :

<cite>
The choice of quantum duration is always a compromise. The rule of thumb adopted by Linux is: choose a duration as long as possible, while keeping good system response time.
</cite>

(extrait du chapitre [http://oreilly.com/catalog/linuxkernel/chapter/ch10.html "Process Scheduling"]).

'''Tourniquet avec priorité.'''
Tous les processus ne naissent pas égaux : certains ont une importance plus élevée (les processus systèmes par exemple). Dans un cas comme le précédent, tous les processus ont le même statut...
Pour corriger ce problème, on utilise parfois un algorithme similaire, mais on choisit le premier processus de priorité la plus élevé possible. Plutôt que de parcourir la file à sa rechercher, on utilise en fait plusieurs files : une pour chaque priorité.

Il faut faire attention car les processus de priorité basse risquent de ne jamais être exécutés (famine)... Par exemple, on peut diminuer petit à petit la priorité des processus qu'on exécute...

Une autre solution pour gérer les priorité en évitant certaines famines est d'exécuter toutes les files, mais pas en proportion égale. Par exemple, on choisit un processus dans les piles de priorité 1, 2, 1, 3, 1, 2, 1, 4, 1, 2, 1, 3, 1, 2, 1, ... De cette manière, les processus de la première file sont exécutés 2 fois plus de fois que ceux de la file 2, et 4 fois plus de fois que ceux de la file 3.

:exercice : donnez un algorithme pour générer la suite précédente pour un nombre donné de files. Il faut que la file ''i'' soit utilisée 2 fois plus souvent que la pile ''i+1''.

'''Répartition garantie.'''
Chaque tache reçoit la même proportion du processeur, et chaque utilisateur reçoit la même proportion également.

'''tirage aléatoire.'''
À chaque étape, on tire un "billet" au hasard, et le processus qui a le "billet gagnant" s'exécute.

Principe de priorité : Les processus qui ont été définit comme prioritaire on plus de "billet" à leur nom et ont donc plus de chance d'être tiré.

''NB : POSIX définit une commande "nice" qui permet e donner à un processus un priorité plus faible (et par conséquent, nice -x augmente cette priorité). Il est évident que tout le monde ne doit pas pouvoir utiliser cette commande, il vaut mieux que l'administrateur se réserve ce droit''

'''Ordonnancement équitable.'''

==La mémoire==

===Introduction===

RAM = Random Acces Memory. C'est ce que l'on appelle couramment la mémoire vive, elle peut être modifié à l'infini et sert à stocker temporairement les fichiers que l'ordinateur exécute.

ROM = Read Only Memory. On l'appelle aussi mémoire fixe ou mémoire morte, dès que l'on enregistre, le contenu d'une mémoire ROM ne peut pas être modifié (ex: un CD-ROM).

'''Gestion de la mémoire : '''

Lors du boot du PC, le système est chargé en mémoire.
Tout processus créé est aussi chargé dans la mémoire.

Lorsque l'on créé uns seul processus, il est plus pratique de le charger en "bas" de la mémoire, à partir de la première case de l'espace mémoire. Puis les nouveaux processus peuvent être charger par dessus. Ainsi la machine comprend où commence l'espace mémoire.

Problèmes :
1 - l'espace d'adressage ne commence pas à 0;
2 - un processus peut demander dynamiquement de la mémoire;
3 - avec un accès direct, un processus peut faire "planter" un autre.

==> Il faut avoir une couche d'abstraction au-dessus de la mémoire physique.

===Espaces d'adressage===

Et si l'on créait des espaces d'adressage distincts pour chaque processus ?
Par exemple : chaque processus utilise des adresse de 0 à n de la mémoire, on converti alors ces adresses en adresses physiques.

Certains des premiers processeurs avaient deux registres supérieurs :

- une Base => adresse physique du début de l'espace d'adressage

- une Limite => adresse physique de fin de l'espace d'adressage

Par exemple, lors de l'exécution d'un processus l'accès à une case "a" se transforme en l'accès à la Base+a et un test pour vérifier que : a+Base < Limite.

Malgré tout, ceci ne résout pas les problèmes liés au fait que des processus sont créés et disparaissent, réclament ou libèrent de la mémoire.

===Va-et-vient (swapping)===

====Idée====

Et si pour gérer tout cela on utilisait une mémoire auxiliaire (disque), pour stocker l'état de la mémoire de processus.

La mémoire vue par les processus ne correspond pas à la mémoire physique. À un instant donné, certains processus peuvent se retrouver sur le disque (dans le SWAP).

Quand un processus apparait, on lui cherche un morceau d'espace libre dans la mémoire.

====gestion de la mémoire====

* tableau de bits
* liste chaînée

====Allocation====

* first fit
* next fit
* best fit
* worst fit

===Mémoire virtuelle===

====Idée====

====Pagination====

====Traduction des adresses====

====Table des pages====

====Table inversée====

====Remplacement des pages====

==Les entrées / sorties==

----
----

==Références==

* le livre « Systèmes d'exploitation » de Andrew Tanenbaum est disponible à la BU
* la page du [http://sos.enix.org/fr/PagePrincipale projet SOS]
* la [http://www.opengroup.org/onlinepubs/009695399/nfindex.html norme POSIX:2004]
* l'[http://msdn.microsoft.com/en-us/library/aa383749(VS.85).aspx API win32]
* [http://www.lemis.com/grog/Documentation/Lions/index.php Commentary on the Sixth Edition UNIX Operating System]

INFO502 : Systèmes d'exploitation

2009-12-11T10:17:59Z

Hatat : /* TP */ Typo

Ce wiki est un complément de cours pour le cours « info-502 : systèmes d'exploitation ». La participation au wiki est fortement encouragée.

Pour pouvoir modifier les pages, inscrivez-vous (lien en haut à droite) pour obtenir un login et mot de passe. (Choisissez un login du style ''PrenomNom''...)

Je vous conseille d'aller lire [http://meta.wikimedia.org/wiki/Aide:Contenu ce guide] pour vous familiariser avec les wikis.

Exercice : si vous n'en avez pas, créez-vous un compte et essayez de modifier cette page (correction de fautes d'hortographe, rajout de détails, mise en page, ...)

Vous pouvez aussi utiliser la page de discussion pour ... discuter. (Ou poser des questions, faire des commentaires etc.)

----
----
==Auteur du cours==

===Nouvelles===

===Supports===

====TD====

Sujets de TD :
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td1.pdf Ordonnancement],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td2.pdf Gestion de la mémoire],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td3.pdf Systèmes de fichiers].

====TP====

# Découverte de SOS :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp1.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp1.tar.gz code source],
#* [http://www.gnu.org/software/grub/manual/multiboot/multiboot.html Multiboot Specification] : SOS respecte la spécification Multiboot, qui dit comment un système d'exploitation doit être chargé en mémoire par GRUB (ou tout autre chargeur respectant cette spécification).
# Gestion de la mémoire du noyau :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp2.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp2.tar.gz code source],
#* Article [http://sos.enix.org/wiki-fr/upload/SOSDownload/sos-texte-art5.pdf Gestion de la mémoire virtuelle du noyau].
# Ordonnancement :
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp3.tar.gz code source].

==Introduction==

-- ...

==Repères historiques==

Voici quelques évènements clés dans l'histoire des systèmes d'exploitation. Pour plus de détails, ou pour des compléments sur l'histoire de l'informatique, je vous renvoie sur Wikipedia : [http://en.wikipedia.org/wiki/History_of_operating_systems "History of operating systems"] et [http://en.wikipedia.org/wiki/History_of_computing "History of computing"].

Les premiers ordinateurs ne comportaient pas vraiment de système d'exploitation : c'étaient des opérateurs humains qui géraient tout. (C'était juste après la seconde guerre mondiale, l faut savoir que les langages de programmation n'existaient même pas...) La petite histoire (??) raconte qu'à un moment, les processus pour l'ordinateur de l'université de Cambridge étaient accrochés sur une corde à linge et que c'était la couleur des pinces à linges qui donnait la priorité. (??)

Le passage à la notion de système d'exploitation c'est faite graduellement pour répondre à la complexité de plus en plus grande des ordinateurs et aux demandes des utilisateurs.

Les premier systèmes d'exploitation datent probablement de 1956. Ils permettaient simplement d'exécuter un nouveau programme lorsque le précédent était terminé. Les ordinateurs d'IBM de la famille System/360 ont ensuite eu toute une série de systèmes d'exploitation plus ou moins similaires : OS/360, DOS/360 (rien à voir avec MS-DOS), TSS/360... C'est à cette époque qu'est apparu la notion de multiprogrammation (possibilité d'avoir plusieurs processus entrelacés.)
C'est également au début des années 60 qu'on a commencé à voir des systèmes avec temps partagé : plusieurs utilisateurs pouvaient utiliser un ordinateur. Le système Multics a été, à ce niveau comme à d'autres, assez révolutionnaire. Multics a été utilisé jusqu'en 2000 !

Multics n'était par contre pas approprié pour les mini-ordinateurs où le nombre d'utilisateur est relativement restreint. En 1969, Ken Thomson
a développé une variante simplifié de Multix : Unix...

Ce n'est qu'un peu plus tard (1979) que la première version de DOS (86-DOS ou QDOS) apparaît. 86-DOS sera racheté par Microsoft un 1980...

'''Liens et compléments :'''
* [http://en.wikipedia.org/wiki/Timeline_of_operating_systems Timeline of operating systems]
* généalogie des systèmes Unix : [http://www.levenez.com/unix/ Unix History]
* généalogie de Windows : [http://www.levenez.com/windows/ Windows History]
* généalogie des systèmes non-Unix : [http://www.oshistory.net/metadot/index.pl?id=2165 timeline of non-Unix operating systems]

==Vue d'ensemble==

Ce cours reste assez généraliste et essaie de regarder les principales fonction d'un système d'exploitation. Les systèmes de type Unix (Linux) sera un exemple privilégié. À cause de leur complexité intrinsèque, les évolutions modernes (architectures multicoeur ou multiprocesseur, ...) seront en partie ignorée dans un premier temps.

Les problèmes fins de communication entres processus ne seront que très peu abordés, car ils font l'objet d'un cours séparé (info604) pour la filière info.

Nous allons suivre l'ordre classique consistant à regarder :
# les processus
# la mémoire
# les entrées / sorties

La fin du cours dépendra du temps restant...

===Les processus===

Un processus est simplement un programme « en exécution ». À tout instant, un ordinateur de bureau contemporain contient de nombreux processus qui doivent partager le (les) processeur(s) pour donner l'impression qu'ils s'exécutent « en même temps ». Un des rôles du système d'exploitation consiste à décider dans quel ordre les processus vont effectivement pouvoir utiliser le processus.

===La mémoire===

La mémoire est, comme le processeur, une ressource partagée par les différents processus. Il faut donc gérer la quantité de mémoire allouée et utilisée pour que les processus n'aient pas à s'occuper de ceci. Un des concepts fondamentaux est celui de mémoire virtuelle. Ceci permet d'offrir un espace mémoire pour chacun des processus de manière transparente.

===Les entrées / sorties===

Un ordinateur n'est pas (plus) un système indépendant du reste du monde : il interagit avec l'extérieur à travers des périphériques d'entrées/sorties (clavier / écran / souris / ...). La gestion de ces périphériques pose un ensemble de problèmes que nous aborderons brièvement...

===...===

Une fois ces notions vues, nous regarderons peut-être les problèmes de sécurité, de multimédia ou des architectures multiprocesseurs.

==Préliminaires==

===Quoi ?===

Les ordinateurs, ou plus simplement les micro contrôleurs sont des circuits électroniques avec une puce « processeur ». Le développement d'applications n'est pas facile si on se place au niveau électronique et que l'on parle directement au CPU. Pour faciliter la vie des programmeurs, plusieurs couches d'abstraction sont nécessaires. La première se place au niveau matériel et s'occupe directement des problèmes électroniques ou de très bas niveau. Il s'agit du ''firmware''. Il répond par exemple aux questions comme :
* qu'elle est l'amplitude des signaux envoyés par l'horloge ?
* est-ce que l'UC possède un pipeline ?
* ...
Un firmware est donc forcement très lié au matériel sur lequel il tourne.

La couche suivante est le système d'exploitation à proprement parler. Dans le cas que vous connaissez le mieux (ordinateur personnel), le système d'exploitation fournit une interface pour :
* exécuter un programme
* exécuter plusieurs programmes « en même temps »
* gérer les ressources (temps processeur, mémoire disponible, entrées / sorties)
* les opérations sur les fichiers
* offrir des garanties de sécurité

===Où ?===

On trouve des systèmes d'exploitation partout :

* dans les ordinateurs personnels (Linux, BSD, MacOS, Solaris, Windows, ChromeOS (?))
* dans les PDA (PalmOS, ...)
* dans les téléphones portables (Android, OpenMoko,Symbian,)
* console de jeux
* lecteur MP3 (Rockbox, ...)
* les microcontroleurs « avancés »

===Comment ?===

====Langage de programmation====

Le système d'exploitation se situe entre le firmware (très bas niveau) et l'utilisateur. La nécessité d'accéder à ces ressources de très bas niveau implique que les langages de haut niveaux (Java, Ada, Python, ...) ne sont pas du tout adaptés à l'écriture des systèmes d'exploitation.
Le langage le plus utilisé reste à ce jours le langage C : Linux, BSD, MacOS, Windows, ... sont tous écrits pour leur plus grande partie en C.

Vous avez normalement un cours de C en parallèle, et les TPs utiliseront le langage C. (La référence sur le langage C reste à mon goût le livre de Kernighan et Ritchie : « the C Programming language ». (Disponible en francais à la BU sous le titre « Le langage C : norme Ansi ».) Il existe de nombreux autres livres / documents sur la programmation C comme le [http://www-clips.imag.fr/commun/bernard.cassagne/Introduction_ANSI_C.html polycopié de Bernard Cassagne « introduction au langage C »].

Les premiers systèmes d'exploitation étaient écrits directement en langage machine, ou bien en langage d'assembleur ; et les systèmes actuels comportent encore quelques parties de très bas niveau en langage d'assemblage...

====Notion d'appel système, norme POSIX====

La programmation de haut niveau en C est assez différente de la programmation système. De nombreuses fonctions C utilisent en fait des « appels système », c'est à dire des appels de fonctionnalités propres du système d'exploitation. Les appels système typiques sont :
* les fonctions relatives aux fichiers (création, suppression, modification...)
* les fonctions relatives à la gestion de la mémoire
* les fonctions relatives aux processus (<tt>fork</tt>)
* ...

De nombreux système d'exploitation proposent une interface [http://en.wikipedia.org/wiki/Posix POSIX] (« '''P'''ortable '''O'''perating '''S'''ystem '''I'''nterface for Uni'''x''' »). Cette norme définit entre autres un ensemble de fonctions pour utiliser les appels systèmes.
Le nombre de ces fonctions est relativement faible : une centaine ; et chacune correspond en gros à un appel système. Certaines de ces fonctions ne sont pas définies directement dans le système d'exploitation, mais dans des librairies. Pour Linux, il s'agit en général de la librairie Glibc (GNU C Library).

Par exemple, la fonction <tt>open</tt> (qui permet d'ouvrir un fichier) correspond exactement à un appel système ; alors que la fonction <tt>malloc</tt> (qui permet d'allouer dynamiquement de la mémoire dans le tas) peut générer plusieurs appels système (<tt>brk</tt> et <tt>sbrk</tt>).

Pour visualiser les appels systèmes effectués par un programme sous Linux, vous pouvez utilisez l'utilitaire <tt>strace</tt> ou <tt>ltrace</tt>. Par exemple, dans le shell :
$ strace -e trace=file ls -l 2> trace
permet de récupérer tous les appels systèmes relatifs aux fichiers lors de l'appel à <tt>ls -l</tt>. La liste des appels système est redirigée dans le fichier <tt>trace</tt> qui contiendra par exemple des lignes telles que
lstat64("Desktop", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lgetxattr("Desktop", "security.selinux", 0x8cc08e0, 255) = -1 ENODATA (No data available)
dénotant ainsi un appel aux appels système <tt>lstat64</tt> et <tt>lgetxattr</tt>...

Les principaux systèmes compatibles POSIX sont :
* Linux
* BSD (et variantes)
* Mac OS X
* Solaris

De nombreux appels systèmes sont disponibles directement (sans avoir besoin d'écrire un programme C) à travers le shell. Exécuté dans un terminal, le shell permet, en première approximation, de passer directement des commandes au système d'exploitation. (La norme POSIX définit également un ensemble de fonctions du shell. Il est donc relativement aisé de changer de système d'exploitation tant qu'on reste dans les systèmes compatibles POSIX.)

Windows d'un autre côté utilise l'interface Win32 API, qui définit plusieurs milliers de fonctions. La plupart de ces fonctions peuvent utiliser plusieurs appels système...

Les systèmes d'exploitation qui utilisent l'API Win32 sont :
* Windows, depuis Windows95.

Il est possible d'installer un environnement compatible POSIX sur une machine Windows grâce à Cygwin. (C'est d'ailleurs fortement conseillé si vous ne voulez pas installer une version de Linux ou BSD sur votre ordinateur personnel...)

====Mode noyau / mode utilisateur====

La partie fondamentale du système d'exploitation est le ''noyau'' (''kernel'' en anglais). C'est la couche de plus bas niveau.

Les fonctionnalités de très bas niveau offertes par le noyau peuvent facilement planter l'ordinateur. Il faut donc une politique de restriction pour que tous les programmes ne puissent y accéder dans leur totalité. On parle de
* mode noyau
* mode utilisateur

Dans le mode utilisateur, on ne peut accéder à ces fonctionnalités qu'a travers les appels systèmes ; dans le mode noyau, on peut tout faire... Bien entendu, un appel système doit passer momentanément en mode noyau pour pouvoir exécuter les commandes pertinentes, puis il repasse automatiquement en mode utilisateur.

La définition d'un appel système pourrait donc être « fonctionnalité atomique nécessitant un passage en mode noyau ».

====Noyau, noyau monolithique, micro-noyau====

La partie principale du système d'exploitation. C'est lui qui gère les ressources, les entrées / sorties, la communication entre processus, ... Les deux architectures principales pour un noyau sont :
* noyau monolithique
* micro-noyau
La plupart des systèmes actuels sont basés sur un noyau monolithique (Linux, BSD, Mac OS X, Solaris, Windows).

Les noyaux monolithiques sont parfois décrits comme « sans vraie structure » : une grosse soupe où cohabitent toutes les fonctionnalités du système d'exploitation. L'idée d'avoir un système unique qui gère tout est effectivement peu attirante et peut poser quelques problèmes de génie logiciel...
Un noyau monolithique est donc la couche entre le matériel et les programmes utilisateurs. Pour éviter de compiler des noyaux énormes, les noyaux monolithiques actuels utilisent en plus la notion de ''module''. Ce sont des morceaux du noyau qu'on peut charger ou décharger au besoin. Si l'interface est connue, ces modules peuvent éventuellement être en binaire, ce qui permet d'utiliser des modules propriétaires avec un noyau libre.
Sous Linux, la commande
$ lsmod
permet d'obtenir la liste des modules chargés dans le noyau.

Les micro-noyaux d'un autre coté sont basés sur la remarque que seule une toute petite partie du noyau accède effectivement au matériel. Seule cette petite partie nécessite donc des privilèges et effectue des appels système. Le reste du système d'exploitation peut être programmé en mode utilisateur, « au dessus » de cette partie. Par exemple, le micro noyau offrira la possibilité de charger un nouveau processus, mais l'ordonnanceur (qui choisit quel processus devra être chargé) ne fera pas partie du micro-noyau. On parle parfois de ''services'' / ''serveurs'' au dessus du micro-noyau.
Ceci permet d'avoir un noyau bas niveau beaucoup plus petit. Bien que ceci soit une bonne idée, et que les micro-noyaux puissent fournir de meilleurs garanties de sécurité, peu de noyaux sont effectivement des micro-noyaux. Un des problèmes est qu'un tel micro-noyau est un peu plus lent que ses cousins monolithiques. La raison principale est que dans le cas d'un micro-noyau, un appel système nécessite en fait des communications inter-processus.
Andrew Tanenbaum est un fervent défenseur des micro-noyaux.

Une autre architecture possible est d'utiliser des couches successives, chacune avec des privilèges réduits. Le système Multics avait cette architecture.
Par exemple, dans le système THE (1965), les couches étaient les suivantes :
# noyau bas niveau, multiprogrammation
# allocation de la mémoire pour les processus
# IPC (communication inter processus)
# entrées / sorties (buffer, etc.)
# programmes utilisateurs (compilation, exécution, ...)
# utilisateur (Dijkstra a annoté la description de cette couche par ''« not implemented by us »'')

Une dernière catégorie de noyau est la catégorie des machines virtuelles. Ces noyaux sont un peu à part, car il s'agit d'émuler un système d'exploitation ou du matériel particulier à l'intérieur d'un autre système d'exploitation ou matériel. Le mode noyau de la machine virtuelle est en fait dans le mode utilisateur du noyau original...

==Les processus==

===Introduction===

Allez hop commençons par une petite définition du type wikipédia :

Un processus (en anglais, process), en informatique, est défini par :
* un ensemble d'instructions à exécuter (un programme) ;
* un espace mémoire pour les données de travail ;
* éventuellement, d'autres ressources, comme des descripteurs de fichiers, des ports réseau, etc.

Un ordinateur équipé d'un système d'exploitation à temps partagé est capable d'exécuter plusieurs processus de façon « quasi- simultanée ». Par analogie avec les télécommunications, on nomme multiplexage (A. Tanenbaum parle de ''multiprogrammation'') ce procédé. S'il y a plusieurs processeurs, le système essaie de répartir les processus de manière équitable sur les processeurs disponibles.

Le processus doit être imaginé comme quelque chose qui prend du temps, donc qui a un début et (parfois) une fin. De nombreux processus ne se terminent normalement jamais : système d'exploitation, serveurs web, serveurs mail, ... D'autres processus plus légers qui ne se terminent pas sont les ''daemon'' (acronyme ''a posteriori'' de "disk and execution monitor") du monde Unix.

Certains processus sont démarrés très tôt lors de la séquence de boot. Le système d'exploitation est un tel processus. Sinon, les processus sont normalement démarrés grâce à un appel système à partir d'un autre processus. L'utilisateur peut par exemple demander explicitement un nouveau processus (sous POSIX, grâce à un <tt>fork</tt> puis <tt>exec</tt>) ; mais la plupart du temps, il le fera à travers une application, par exemple en double-cliquant sur l'icône d'un programme dans l'explorateur de fichiers.

Le système d'exploitation est chargé d'allouer les ressources (mémoires, temps processeur, entrées/sorties) nécessaires aux processus et d'assurer que le fonctionnement d'un processus n'interfère pas avec celui des autres (isolation).

Pas sûr d'avoir tout compris ? Ce n'est pas grave, essayons autrement.
:'''Définition :''' un processus est un programme en train de s'exécuter.
Cette définition implique en particulier que un programme (navigateur Firefox par exemple) peut correspondre à
* zéro processus si on ne l'a pas lancé,
* un processus si on l'a lancé,
* plusieurs processus si on l'a lancé plusieurs fois.
(''Remarque :'' pour un programme comme Firefox, il y a fort à parier que l'exécution d'une seule instance de Firefox génère de multiples sous-processus...)

Que se passe-t-il quand je démarre une application?

:L'ordinateur à une nouvelle tâche à accomplir, les instructions correspondantes sont donc envoyées au processeur. Comme il a plusieurs choses à faire le choix des instructions à exécuter n'est pas forcement simple. Il faut faire en sorte de partager le processeur entre les différentes tâches de manière équitable : c'est la fameuse gestion des processus.
:Ceci permet de réaliser plusieurs activités en ~même temps~. Grâce à la gestion des processus on peut regarder un film (obtenu par des moyens tout à fait légaux cela va de soit), tout en jouant à la dame de pique.
:(et dire que certain(e)s affirment que l'homme est mono tâche)

Plusieurs processus indépendants peuvent être ''actifs'' en même temps, mais sauf si l'ordinateur possède suffisamment de processeurs, on ne peut pas les exécuter simultanément. L'impression que plusieurs programmes s'exécutent ''en même temps'' vient simplement du fait que le processeur alterne rapidement entre eux.
Comme le temps d'exécution d'une instruction par le processeur est très court, de l'ordre de la nano-seconde, le processeur peut réaliser plusieurs centaines de millions d'instructions par seconde. Ainsi, une tranche de temps de quelques fractions de seconde, partagée entre plusieurs processus, donne à l'échelle macroscopique l'illusion de la simultanéité.

'''En résumé :''' un système d'exploitation doit la plupart du temps traiter plusieurs tâches en même temps, et comme il n'a, en général, qu'un seul processeur, il devra contourner ce problème grâce à un pseudo-parallélisme. Il traite une tâche à la fois, s'interrompt et passe à la suivante. La commutation de tâches étant très rapide, il donne l'illusion d'effectuer un traitement simultané.

===La table des processus===

L'information sur les processus est conservé par le système dans une structure de données appelée ''table des processus''. Cette table contient toutes les informations nécessaires à la gestion des processus :
* état du processus
* PID
* droits
* répertoire de travail
* pointeur vers la pile
* priorités
* ...

Sous Linux, on peut accéder à ces informations à travers le système de fichiers virtuel "Procfs". Il suffit d'aller dans le répertoire <tt>/proc/</tt>.

===Création d'un processus===

Pour les système POSIX, la création d'un processus est très simple : on utilise la fonction <tt>fork()</tt>. En C, le prototype de la fonction se trouve dans le fichier d'entêtes <tt>unistd.h</tt>.

Cette fonction prend 0 argument et permet de faire la chose suivante : elle crée un nouveau processus qui est une copie conforme du processus appelant. La seule différence visible entre l'ancien et le nouveau processus est que les processus ont un numéro (PID) différent. Pour le processus appelant, il peut obtenir le PID du nouveau processus en regardant la valeur de retour de <tt>fork</tt>. Pour le nouveau processus, cette valeur vaudra 0, et il devra utiliser la fonction <tt>getpid()</tt> pour obtenir son numéro.

Le processus appelant est appelé le ''père'' alors que le nouveau processus est appelé le ''fils''.

Notez que l'espace mémoire du processus est dupliqué plutôt que partagé. Ceci veut dire que les processus ne peuvent pas communiquer en utilisant leur variables... Par contre, les descripteurs de fichiers du fils sont hérités directement de ceux du père ; ils peuvent donc essayer de communiquer en passant par ces fichiers. (Mais cela pose de nombreux problèmes de synchronisation.)

Voici par exemple un petit programme C qui lance un processus fils:
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {

int pid ;
int pid_fils ;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
} else {
printf(" >> Je suis le fils.\n");
}

return(0);

}
Après compilation, voici un exemple d'exécution du programme résultant :
$ ./pere_fils
> Le processus 8248 démarre...
>> Je suis le fils.
>> Je suis le père (pid du fils = 8249).

Voici un autre exemple d'exécution :
$ ./pere_fils
> Le processus 8269 démarre...
>> Je suis le père (pid du fils = 8270).
>> Je suis le fils.

Notez que les numéros sont différents, et que l'ordre d'affichage n'est pas le même. Cela vient de l'ordonnancement des deux processus qui peut différer.

La technique consistant à faire
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
...
}
montre que malgré le fait que les processus soient identiques à l'origine, on peut faire beaucoup de chose.

:'''Remarque :''' <tt>fork()</tt> n'est pas directement un appel système, mais une fonction qui utilise l'appel système <tt>clone()</tt>. Cet appel système ne fait pas partie de la norme POSIX...

La deuxième technique utilisée dans les systèmes POSIX consiste à utiliser <tt>fork()</tt> pour dupliquer le processus, puis à complètement remplacer le fils par un nouveau processus. La fonction correspondante est la fonction <tt>execv</tt> :
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
execv("/usr/bin/...", argv);
...
}
La fonction <tt>execv</tt> prend 2 arguments : une chaîne contenant le chemin d'accès à un programme, et un tableau d'arguments à donner au programme. (C'est un peu plus compliqué que ça : le premier élément du tableau est le nom du programme, et le tableau doit se terminer par un pointeur NULL.)

Une dernière fonction importante est la fonction <tt>wait(pid)</tt> qui permet à un processus d'attendre l'arrêt du processus <tt>pid</tt>.

-- ...

L'API WIN32 possède de nombreuses fonctions avec des fonctionnalités similaires. Par exemple, la fonction [http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx <tt>CreateProcess</tt>] permet de créer un nouveau processus (comme un <tt>fork</tt> suivi d'un <tt>exec</tt>), mais elle nécessite ... 10 arguments !

----

Un autre moyen de créer des processus est d'utiliser des 'processus légers' appelés Thread. Ces processus légers partage seulement une partie de la mémoire, ce qui en pratique est plus rapide pour simuler un parallélisme. On passe alors par une autre fonction. Sous GNU/Linux, lors de l'écriture d'un programme écrit en C il faut utiliser la bibliothèque pthread.h et lors de la compilation, faire un lien vers celle ci, en utilisant le paramètre -lpthread.

====Arborescence des processus dans les systèmes POSIX====

Nous avons vu que la fonction <tt>fork()</tt> permet de créer un processus fils. Le père connaît le PID de son fils : il lui est donné par la fonction <tt>fork()</tt>. Comme le fils peut lui même créer des processus fils, on obtient rapidement une arborescence de processus.

Vous pouvez visualiser cette arborescence à partir d'un terminal avec la commande <tt>pstree</tt> (l'option <tt>-p</tt> permet de demander l'affichage des PID)
$ pstree -p
init(1)─┬─acpid(25425)
├─atd(14365)
├─console-kit-dae(3632)─┬─{console-kit-dae}(3633)
│ ├─{console-kit-dae}(3641)
...
├─cron(14315)
├─dbus-daemon(15590)
├─dbus-daemon(3511)
...
├─getty(4095)
├─getty(4096)
├─getty(4097)
├─getty(4098)
├─getty(4099)
├─gpm(3528)
...
├─kded4(15769)
├─kdeinit4(15766)───klauncher(15767)
├─kdm(15564)─┬─Xorg(15566)
│ └─kdm(15573)───sh(15608)─┬─conky(15751)
│ ├─fluxbox(15703)───firefox-bin(6063)─┬─{firefox-bin}(6064)
│ │ ├─{firefox-bin}(6065)
...
│ ├─ssh-agent(15698)
│ ├─unclutter(15742)
│ ├─wicd-client(15749)
│ └─xscreensaver(15683)
...
├─rsyslogd(6850)─┬─{rsyslogd}(6140)
│ └─{rsyslogd}(6141)
├─screen(4427)─┬─bash(4428)───pstree(9307)
│ ├─bash(4429)───man(7952)───pager(7965)
│ ├─bash(4430)───vi(30568)
│ ├─bash(18395)───vi(28512)
│ └─mutt(8763)
...

Le processus <tt>init</tt> est l'ancêtre de tout les processus, il a toujours 1 comme PID.

'''Remarque :''' sous Windows, les processus ne sont pas organisé en arborescence...

====Mort d'un processus dans un système POSIX====

Un processus peut se terminer pour plusieurs raisons :
* volontairement, grâce à la fonction <tt>exit()</tt> (POSIX) ou <tt>ExitProcess()</tt> (Windows),
* à cause d'une erreur,
* en recevant un signal d'un autre processus, grâce à la fonction <tt>kill()</tt> (POSIX) ou <tt>TerminateProcess()</tt> (Windows).

Lorsqu'un processus se termine, plusieurs choix sont possibles :
* que fait-on de ses fils ?
* que fait-on de son père ?

Linux fait la chose suivante : quand un processus s'arrête,
* tous ces fils s'arrêtent,
* son père reçoit un signal le prévenant que son fils vient de mourir.

Pour que le père puisse recevoir le signal correspondant, il faut qu'il utilise la fonction <tt>wait()</tt> ou <tt>waitpid()</tt>. Tant que le parent existe et qu'il n'a pas reçu le signal disant qu'un de ces fils est mort, le processus fils n'est pas entièrement supprimé : il devient un ''zombie''. (Il n'occupe plus vraiment de place en mémoire, mais le système garde juste suffisamment d'information pour pouvoir prévenir le père si celui ci demande l'état du fils.)

'''Remarque :''' les processus Windows ne sont pas organisés sous forme d'arborescence. Chaque processus peut surveiller l'état d'un autre processus, s'il connaît son PID. Il n'y a donc pas de notion de processus ''zombie'' sous Windows.

Voici un petit programme C qui crée un processus fils, ne fait rien pendant 20 secondes, puis demande l'état de son fils :
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
int pid ;
int pid_fils ;
int w;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
printf(" >> Je suis le père et j'attends un peu.\n");
sleep(20);
printf(" >> Je suis le père et je demande l'état de mon fils.\n");
wait(&w);
printf(" >> Mon fils est mort (signal %i).\n", w);
while(1) sleep(1);
} else {
printf(" >> Je suis le fils.\n");
while (1) sleep(1);
exit(0);
}
return(0);
}
Si on tue le processus fils pendant que le père ne fait rien, le processus fils devient un zombie. Dès que le père fait le <tt>wait</tt>, il reçoit la valeur du signal qui a terminé le processus et le zombie disparaît.

Si on ne tue pas le processus fils, le père n'exécutera jamais le <tt>printf(" >> Mon fils est mort...);</tt>.

'''Remarque :''' dans un système POSIX, lorsqu'un processus meurt, ses fils deviennent ''orphelins''. Il continuent leur exécution mais sont adopté par <tt>init</tt> (PID : 1). Dans certains cas lorsque le processus est arrêté, il envoie explicitement un signal <tt>SIGTERM</tt> pour tuer ses processus fils. C'est par exemple ce qui arrive lorsqu'on lance des application à partir d'un terminal et que l'on quitte le terminal en question...

===États d'un processus===

On peut imaginer un SE dans lequel les processus pourraient être dans trois états :
* en cours d'exécution,
*bloqué : il attend un événement extérieur pour pouvoir continuer (par exemple une ressource; lorsque la ressource est disponible, il passe à l'état "prêt")
*prêt : suspendu provisoirement pour permettre l'exécution d'un autre processus.

Dans un système avec un unique processeur, au plus un processus peut se trouver dans l'état ''en cours d'exécution''. Par contre, il peut y avoir de nombreux processus dans l'état ''bloqué'' ou dans l'état ''prêt''.

Un processus peut passer d'un état à l'autre :
# de ''en exécution'' à ''bloqué'' lorsqu'une ressource n'est pas disponible (entrées / sortie par exemple),
# de ''bloqué'' à ''prêt'' si la ressource ayant provoqué le blocage devient disponible,
# de ''en exécution'' à ''prêt'' si le système décide de suspendre l'exécution du processus,
# de ''prêt'' à ''en exécution'' si le système décide de lancer l'exécution du processus.

On peut résumer ceci par le graphe de transitions suivant :

[[Image:Diagrammedétatdunprocessus.png]]

Les transition manquantes ne sont pas possible directement mais doivent passer par des transition intermédiaires.

On peut ajouter 2 états :
* ''nouveau'' pour un processus qui vient d'être créé,
* ''terminé'' pour un processus qui vient de se terminé.

Dans les systèmes type ''ordinateur de bureau'', le passage de ''nouveau'' à ''prêt'' est automatique mais dans des systèmes temps réel, un processus peut parfois attendre dans cet état.

L'état ''terminé'' est en général passager. Par exemple, lorsqu'un processus terminé est un zombie, le processus n'est conservé que dans la table des processus. La mémoire utilisé par le processus est libérée. La question de savoir si ceci est véritablement un état du processus est donc essentiellement une question de vocabulaire.

:exercice : ajouter les états ''nouveau'' et ''terminé'' et les transitions correspondantes au graphe précédent. Identifiez des situations provoquant les transitions possibles entre états.

===Ordonnancement des processus===

Nous avons vu qu'il pouvait y avoir de nombreux processus dans la table de processus (environ 150 sur mon ordinateur en ce moment même). Parmi ces processus, un seul (sur une machine à un processeur) peut se trouver dans l'état ''en exécution''. C'est au système d'exploitation de décider qui, à un moment donnée, doit se trouver dans cet état. La partie du système faisant ceci s'appelle ''ordonnanceur'' (ou ''scheduler'' en anglais).
En utilisant le contenu de la table des processus et éventuellement d'autres information, ordonnanceur doit donc gérer les transition entre états de tous les processus, et envoyer l'information nécessaire aux composants adéquat du noyau.

Comme d'habitude, l'ordonnanceur doit faire des compromis entre :
* la vitesse,
* l'utilisation de la mémoire,
* l'optimalité de la solution proposée.

'''Remarque : ''' l'ordonnanceur est lui même un processus (ou un morceau de processus dans le cas des noyaux monolithiques).

====Ordonnancement non préemptif====

'''FIFO.'''
L'algorithme d'ordonnancement le plus facile est probablement celui de type ''FIFO'' : premier arrivé, premier servi. Autrement dit, on préempte premier processus arrivé, et on l'exécute jusqu'à la fin. La seul structure de donnée est donc simplement une ''file''.

'''Plus court temps d'exécution.'''
Dans certain cas, on peut prévoir a l'avance le temps processeur dont aura besoin un processus pour s'exécuter. On peut alors choisir le processus le plus court et l'exécuter en premier. Ceci a en général tendance à diminuer le temps d'attente moyen d'un processus ; mais si des processus courts sont crées régulièrement, on peut assister à une ''famine'' : un processus peut ne jamais s'exécuter.

:exercice : trouver une suite de processus qui provoque une famine.

Ces deux exemples sont acceptables pour un ''traitement par lots'' (batch) par exemple pour des calculs numériques. Ils ne sont par contre pas du tout adaptés pour un ordinateur personnel ou un système temps réels. (Pas de ''multiprogrammation''.)

====Ordonnancement préemptif====

Pour pouvoir donner l'illusion de simultanéité, les processus sont en général exécutés par tranches de temps spécifiées à l'avance (''time slice'' en anglais). Au bout de ce temps, le noyau reçoit une interruption et examine les processus. Il peut décider de continuer le processus courant, ou bien le remplacer par un autre processus. on parle de préemption.

Windows 3.1 ou MacOS 9 étaient des systèmes ''collaboratifs'' car les processus devaient explicitement laisser la main aux autres processus. Tous les systèmes d'exploitation modernes sont maintenant préemptifs. On parle maintenant de système préemptif lorsque la préemption peut s'effectuer même sur des processus en mode noyau.
On parle parfois de noyau préemptible lorsque que les opérations en mode noyau sont elle même préemptibles.

'''Tourniquet.'''
L'algorithme le plus simple est probablement celui du tourniquet (''round Robin'' en anglais). C'est une variante de l'algorithme FIFO vu plus haut, mais qui préempte le processus courant au bout d'un moment. Si ce processus est encore en exécution, on le remet à la fin de la file des processus.

Le temps imparti à chaque processus ne doit pas être trop court (sinon, le changement de contexte prend trop de temps par rapport à l'exécution des processus) ni trop long (sinon, on perd l'illusion de parallélisme, et un processus bloqué risque d'occuper le processeur pendant trop longtemps).

Voici ce qu'on peut trouver dans le livre "Understanding the Linux kernel" :

<cite>
The choice of quantum duration is always a compromise. The rule of thumb adopted by Linux is: choose a duration as long as possible, while keeping good system response time.
</cite>

(extrait du chapitre [http://oreilly.com/catalog/linuxkernel/chapter/ch10.html "Process Scheduling"]).

'''Tourniquet avec priorité.'''
Tous les processus ne naissent pas égaux : certains ont une importance plus élevée (les processus systèmes par exemple). Dans un cas comme le précédent, tous les processus ont le même statut...
Pour corriger ce problème, on utilise parfois un algorithme similaire, mais on choisit le premier processus de priorité la plus élevé possible. Plutôt que de parcourir la file à sa rechercher, on utilise en fait plusieurs files : une pour chaque priorité.

Il faut faire attention car les processus de priorité basse risquent de ne jamais être exécutés (famine)... Par exemple, on peut diminuer petit à petit la priorité des processus qu'on exécute...

Une autre solution pour gérer les priorité en évitant certaines famines est d'exécuter toutes les files, mais pas en proportion égale. Par exemple, on choisit un processus dans les piles de priorité 1, 2, 1, 3, 1, 2, 1, 4, 1, 2, 1, 3, 1, 2, 1, ... De cette manière, les processus de la première file sont exécutés 2 fois plus de fois que ceux de la file 2, et 4 fois plus de fois que ceux de la file 3.

:exercice : donnez un algorithme pour générer la suite précédente pour un nombre donné de files. Il faut que la file ''i'' soit utilisée 2 fois plus souvent que la pile ''i+1''.

'''Répartition garantie.'''
Chaque tache reçoit la même proportion du processeur, et chaque utilisateur reçoit la même proportion également.

'''tirage aléatoire.'''
À chaque étape, on tire un "billet" au hasard, et le processus qui a le "billet gagnant" s'exécute.

Principe de priorité : Les processus qui ont été définit comme prioritaire on plus de "billet" à leur nom et ont donc plus de chance d'être tiré.

''NB : POSIX définit une commande "nice" qui permet e donner à un processus un priorité plus faible (et par conséquent, nice -x augmente cette priorité). Il est évident que tout le monde ne doit pas pouvoir utiliser cette commande, il vaut mieux que l'administrateur se réserve ce droit''

'''Ordonnancement équitable.'''

==La mémoire==

===Introduction===

RAM = Random Acces Memory. C'est ce que l'on appelle couramment la mémoire vive, elle peut être modifié à l'infini et sert à stocker temporairement les fichiers que l'ordinateur exécute.

ROM = Read Only Memory. On l'appelle aussi mémoire fixe ou mémoire morte, dès que l'on enregistre, le contenu d'une mémoire ROM ne peut pas être modifié (ex: un CD-ROM).

'''Gestion de la mémoire : '''

Lors du boot du PC, le système est chargé en mémoire.
Tout processus créé est aussi chargé dans la mémoire.

Lorsque l'on créé uns seul processus, il est plus pratique de le charger en "bas" de la mémoire, à partir de la première case de l'espace mémoire. Puis les nouveaux processus peuvent être charger par dessus. Ainsi la machine comprend où commence l'espace mémoire.

Problèmes :
1 - l'espace d'adressage ne commence pas à 0;
2 - un processus peut demander dynamiquement de la mémoire;
3 - avec un accès direct, un processus peut faire "planter" un autre.

==> Il faut avoir une couche d'abstraction au-dessus de la mémoire physique.

===Espaces d'adressage===

Et si l'on créait des espaces d'adressage distincts pour chaque processus ?
Par exemple : chaque processus utilise des adresse de 0 à n de la mémoire, on converti alors ces adresses en adresses physiques.

Certains des premiers processeurs avaient deux registres supérieurs :

- une Base => adresse physique du début de l'espace d'adressage

- une Limite => adresse physique de fin de l'espace d'adressage

Par exemple, lors de l'exécution d'un processus l'accès à une case "a" se transforme en l'accès à la Base+a et un test pour vérifier que : a+Base < Limite.

Malgré tout, ceci ne résout pas les problèmes liés au fait que des processus sont créés et disparaissent, réclament ou libèrent de la mémoire.

===Va-et-vient (swapping)===

====Idée====

Et si pour gérer tout cela on utilisait une mémoire auxiliaire (disque), pour stocker l'état de la mémoire de processus.

La mémoire vue par les processus ne correspond pas à la mémoire physique. À un instant donné, certains processus peuvent se retrouver sur le disque (dans le SWAP).

Quand un processus apparait, on lui cherche un morceau d'espace libre dans la mémoire.

====gestion de la mémoire====

* tableau de bits
* liste chaînée

====Allocation====

* first fit
* next fit
* best fit
* worst fit

===Mémoire virtuelle===

====Idée====

====Pagination====

====Traduction des adresses====

====Table des pages====

====Table inversée====

====Remplacement des pages====

==Les entrées / sorties==

----
----

==Références==

* le livre « Systèmes d'exploitation » de Andrew Tanenbaum est disponible à la BU
* la page du [http://sos.enix.org/fr/PagePrincipale projet SOS]
* la [http://www.opengroup.org/onlinepubs/009695399/nfindex.html norme POSIX:2004]
* l'[http://msdn.microsoft.com/en-us/library/aa383749(VS.85).aspx API win32]
* [http://www.lemis.com/grog/Documentation/Lions/index.php Commentary on the Sixth Edition UNIX Operating System]

INFO502 : Systèmes d'exploitation

2009-12-11T10:17:46Z

Hatat : /* TP */ Archive TP3

Ce wiki est un complément de cours pour le cours « info-502 : systèmes d'exploitation ». La participation au wiki est fortement encouragée.

Pour pouvoir modifier les pages, inscrivez-vous (lien en haut à droite) pour obtenir un login et mot de passe. (Choisissez un login du style ''PrenomNom''...)

Je vous conseille d'aller lire [http://meta.wikimedia.org/wiki/Aide:Contenu ce guide] pour vous familiariser avec les wikis.

Exercice : si vous n'en avez pas, créez-vous un compte et essayez de modifier cette page (correction de fautes d'hortographe, rajout de détails, mise en page, ...)

Vous pouvez aussi utiliser la page de discussion pour ... discuter. (Ou poser des questions, faire des commentaires etc.)

----
----
==Auteur du cours==

===Nouvelles===

===Supports===

====TD====

Sujets de TD :
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td1.pdf Ordonnancement],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td2.pdf Gestion de la mémoire],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td3.pdf Systèmes de fichiers].

====TP====

# Découverte de SOS :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp1.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp1.tar.gz code source],
#* [http://www.gnu.org/software/grub/manual/multiboot/multiboot.html Multiboot Specification] : SOS respecte la spécification Multiboot, qui dit comment un système d'exploitation doit être chargé en mémoire par GRUB (ou tout autre chargeur respectant cette spécification).
# Gestion de la mémoire du noyau :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp2.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp2.tar.gz code source],
#* Article [http://sos.enix.org/wiki-fr/upload/SOSDownload/sos-texte-art5.pdf Gestion de la mémoire virtuelle du noyau].
# Ordonnancement :
#* #* [http://www.lama.univ-savoie.fr/~hatat/sos-tp3.tar.gz code source].

==Introduction==

-- ...

==Repères historiques==

Voici quelques évènements clés dans l'histoire des systèmes d'exploitation. Pour plus de détails, ou pour des compléments sur l'histoire de l'informatique, je vous renvoie sur Wikipedia : [http://en.wikipedia.org/wiki/History_of_operating_systems "History of operating systems"] et [http://en.wikipedia.org/wiki/History_of_computing "History of computing"].

Les premiers ordinateurs ne comportaient pas vraiment de système d'exploitation : c'étaient des opérateurs humains qui géraient tout. (C'était juste après la seconde guerre mondiale, l faut savoir que les langages de programmation n'existaient même pas...) La petite histoire (??) raconte qu'à un moment, les processus pour l'ordinateur de l'université de Cambridge étaient accrochés sur une corde à linge et que c'était la couleur des pinces à linges qui donnait la priorité. (??)

Le passage à la notion de système d'exploitation c'est faite graduellement pour répondre à la complexité de plus en plus grande des ordinateurs et aux demandes des utilisateurs.

Les premier systèmes d'exploitation datent probablement de 1956. Ils permettaient simplement d'exécuter un nouveau programme lorsque le précédent était terminé. Les ordinateurs d'IBM de la famille System/360 ont ensuite eu toute une série de systèmes d'exploitation plus ou moins similaires : OS/360, DOS/360 (rien à voir avec MS-DOS), TSS/360... C'est à cette époque qu'est apparu la notion de multiprogrammation (possibilité d'avoir plusieurs processus entrelacés.)
C'est également au début des années 60 qu'on a commencé à voir des systèmes avec temps partagé : plusieurs utilisateurs pouvaient utiliser un ordinateur. Le système Multics a été, à ce niveau comme à d'autres, assez révolutionnaire. Multics a été utilisé jusqu'en 2000 !

Multics n'était par contre pas approprié pour les mini-ordinateurs où le nombre d'utilisateur est relativement restreint. En 1969, Ken Thomson
a développé une variante simplifié de Multix : Unix...

Ce n'est qu'un peu plus tard (1979) que la première version de DOS (86-DOS ou QDOS) apparaît. 86-DOS sera racheté par Microsoft un 1980...

'''Liens et compléments :'''
* [http://en.wikipedia.org/wiki/Timeline_of_operating_systems Timeline of operating systems]
* généalogie des systèmes Unix : [http://www.levenez.com/unix/ Unix History]
* généalogie de Windows : [http://www.levenez.com/windows/ Windows History]
* généalogie des systèmes non-Unix : [http://www.oshistory.net/metadot/index.pl?id=2165 timeline of non-Unix operating systems]

==Vue d'ensemble==

Ce cours reste assez généraliste et essaie de regarder les principales fonction d'un système d'exploitation. Les systèmes de type Unix (Linux) sera un exemple privilégié. À cause de leur complexité intrinsèque, les évolutions modernes (architectures multicoeur ou multiprocesseur, ...) seront en partie ignorée dans un premier temps.

Les problèmes fins de communication entres processus ne seront que très peu abordés, car ils font l'objet d'un cours séparé (info604) pour la filière info.

Nous allons suivre l'ordre classique consistant à regarder :
# les processus
# la mémoire
# les entrées / sorties

La fin du cours dépendra du temps restant...

===Les processus===

Un processus est simplement un programme « en exécution ». À tout instant, un ordinateur de bureau contemporain contient de nombreux processus qui doivent partager le (les) processeur(s) pour donner l'impression qu'ils s'exécutent « en même temps ». Un des rôles du système d'exploitation consiste à décider dans quel ordre les processus vont effectivement pouvoir utiliser le processus.

===La mémoire===

La mémoire est, comme le processeur, une ressource partagée par les différents processus. Il faut donc gérer la quantité de mémoire allouée et utilisée pour que les processus n'aient pas à s'occuper de ceci. Un des concepts fondamentaux est celui de mémoire virtuelle. Ceci permet d'offrir un espace mémoire pour chacun des processus de manière transparente.

===Les entrées / sorties===

Un ordinateur n'est pas (plus) un système indépendant du reste du monde : il interagit avec l'extérieur à travers des périphériques d'entrées/sorties (clavier / écran / souris / ...). La gestion de ces périphériques pose un ensemble de problèmes que nous aborderons brièvement...

===...===

Une fois ces notions vues, nous regarderons peut-être les problèmes de sécurité, de multimédia ou des architectures multiprocesseurs.

==Préliminaires==

===Quoi ?===

Les ordinateurs, ou plus simplement les micro contrôleurs sont des circuits électroniques avec une puce « processeur ». Le développement d'applications n'est pas facile si on se place au niveau électronique et que l'on parle directement au CPU. Pour faciliter la vie des programmeurs, plusieurs couches d'abstraction sont nécessaires. La première se place au niveau matériel et s'occupe directement des problèmes électroniques ou de très bas niveau. Il s'agit du ''firmware''. Il répond par exemple aux questions comme :
* qu'elle est l'amplitude des signaux envoyés par l'horloge ?
* est-ce que l'UC possède un pipeline ?
* ...
Un firmware est donc forcement très lié au matériel sur lequel il tourne.

La couche suivante est le système d'exploitation à proprement parler. Dans le cas que vous connaissez le mieux (ordinateur personnel), le système d'exploitation fournit une interface pour :
* exécuter un programme
* exécuter plusieurs programmes « en même temps »
* gérer les ressources (temps processeur, mémoire disponible, entrées / sorties)
* les opérations sur les fichiers
* offrir des garanties de sécurité

===Où ?===

On trouve des systèmes d'exploitation partout :

* dans les ordinateurs personnels (Linux, BSD, MacOS, Solaris, Windows, ChromeOS (?))
* dans les PDA (PalmOS, ...)
* dans les téléphones portables (Android, OpenMoko,Symbian,)
* console de jeux
* lecteur MP3 (Rockbox, ...)
* les microcontroleurs « avancés »

===Comment ?===

====Langage de programmation====

Le système d'exploitation se situe entre le firmware (très bas niveau) et l'utilisateur. La nécessité d'accéder à ces ressources de très bas niveau implique que les langages de haut niveaux (Java, Ada, Python, ...) ne sont pas du tout adaptés à l'écriture des systèmes d'exploitation.
Le langage le plus utilisé reste à ce jours le langage C : Linux, BSD, MacOS, Windows, ... sont tous écrits pour leur plus grande partie en C.

Vous avez normalement un cours de C en parallèle, et les TPs utiliseront le langage C. (La référence sur le langage C reste à mon goût le livre de Kernighan et Ritchie : « the C Programming language ». (Disponible en francais à la BU sous le titre « Le langage C : norme Ansi ».) Il existe de nombreux autres livres / documents sur la programmation C comme le [http://www-clips.imag.fr/commun/bernard.cassagne/Introduction_ANSI_C.html polycopié de Bernard Cassagne « introduction au langage C »].

Les premiers systèmes d'exploitation étaient écrits directement en langage machine, ou bien en langage d'assembleur ; et les systèmes actuels comportent encore quelques parties de très bas niveau en langage d'assemblage...

====Notion d'appel système, norme POSIX====

La programmation de haut niveau en C est assez différente de la programmation système. De nombreuses fonctions C utilisent en fait des « appels système », c'est à dire des appels de fonctionnalités propres du système d'exploitation. Les appels système typiques sont :
* les fonctions relatives aux fichiers (création, suppression, modification...)
* les fonctions relatives à la gestion de la mémoire
* les fonctions relatives aux processus (<tt>fork</tt>)
* ...

De nombreux système d'exploitation proposent une interface [http://en.wikipedia.org/wiki/Posix POSIX] (« '''P'''ortable '''O'''perating '''S'''ystem '''I'''nterface for Uni'''x''' »). Cette norme définit entre autres un ensemble de fonctions pour utiliser les appels systèmes.
Le nombre de ces fonctions est relativement faible : une centaine ; et chacune correspond en gros à un appel système. Certaines de ces fonctions ne sont pas définies directement dans le système d'exploitation, mais dans des librairies. Pour Linux, il s'agit en général de la librairie Glibc (GNU C Library).

Par exemple, la fonction <tt>open</tt> (qui permet d'ouvrir un fichier) correspond exactement à un appel système ; alors que la fonction <tt>malloc</tt> (qui permet d'allouer dynamiquement de la mémoire dans le tas) peut générer plusieurs appels système (<tt>brk</tt> et <tt>sbrk</tt>).

Pour visualiser les appels systèmes effectués par un programme sous Linux, vous pouvez utilisez l'utilitaire <tt>strace</tt> ou <tt>ltrace</tt>. Par exemple, dans le shell :
$ strace -e trace=file ls -l 2> trace
permet de récupérer tous les appels systèmes relatifs aux fichiers lors de l'appel à <tt>ls -l</tt>. La liste des appels système est redirigée dans le fichier <tt>trace</tt> qui contiendra par exemple des lignes telles que
lstat64("Desktop", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lgetxattr("Desktop", "security.selinux", 0x8cc08e0, 255) = -1 ENODATA (No data available)
dénotant ainsi un appel aux appels système <tt>lstat64</tt> et <tt>lgetxattr</tt>...

Les principaux systèmes compatibles POSIX sont :
* Linux
* BSD (et variantes)
* Mac OS X
* Solaris

De nombreux appels systèmes sont disponibles directement (sans avoir besoin d'écrire un programme C) à travers le shell. Exécuté dans un terminal, le shell permet, en première approximation, de passer directement des commandes au système d'exploitation. (La norme POSIX définit également un ensemble de fonctions du shell. Il est donc relativement aisé de changer de système d'exploitation tant qu'on reste dans les systèmes compatibles POSIX.)

Windows d'un autre côté utilise l'interface Win32 API, qui définit plusieurs milliers de fonctions. La plupart de ces fonctions peuvent utiliser plusieurs appels système...

Les systèmes d'exploitation qui utilisent l'API Win32 sont :
* Windows, depuis Windows95.

Il est possible d'installer un environnement compatible POSIX sur une machine Windows grâce à Cygwin. (C'est d'ailleurs fortement conseillé si vous ne voulez pas installer une version de Linux ou BSD sur votre ordinateur personnel...)

====Mode noyau / mode utilisateur====

La partie fondamentale du système d'exploitation est le ''noyau'' (''kernel'' en anglais). C'est la couche de plus bas niveau.

Les fonctionnalités de très bas niveau offertes par le noyau peuvent facilement planter l'ordinateur. Il faut donc une politique de restriction pour que tous les programmes ne puissent y accéder dans leur totalité. On parle de
* mode noyau
* mode utilisateur

Dans le mode utilisateur, on ne peut accéder à ces fonctionnalités qu'a travers les appels systèmes ; dans le mode noyau, on peut tout faire... Bien entendu, un appel système doit passer momentanément en mode noyau pour pouvoir exécuter les commandes pertinentes, puis il repasse automatiquement en mode utilisateur.

La définition d'un appel système pourrait donc être « fonctionnalité atomique nécessitant un passage en mode noyau ».

====Noyau, noyau monolithique, micro-noyau====

La partie principale du système d'exploitation. C'est lui qui gère les ressources, les entrées / sorties, la communication entre processus, ... Les deux architectures principales pour un noyau sont :
* noyau monolithique
* micro-noyau
La plupart des systèmes actuels sont basés sur un noyau monolithique (Linux, BSD, Mac OS X, Solaris, Windows).

Les noyaux monolithiques sont parfois décrits comme « sans vraie structure » : une grosse soupe où cohabitent toutes les fonctionnalités du système d'exploitation. L'idée d'avoir un système unique qui gère tout est effectivement peu attirante et peut poser quelques problèmes de génie logiciel...
Un noyau monolithique est donc la couche entre le matériel et les programmes utilisateurs. Pour éviter de compiler des noyaux énormes, les noyaux monolithiques actuels utilisent en plus la notion de ''module''. Ce sont des morceaux du noyau qu'on peut charger ou décharger au besoin. Si l'interface est connue, ces modules peuvent éventuellement être en binaire, ce qui permet d'utiliser des modules propriétaires avec un noyau libre.
Sous Linux, la commande
$ lsmod
permet d'obtenir la liste des modules chargés dans le noyau.

Les micro-noyaux d'un autre coté sont basés sur la remarque que seule une toute petite partie du noyau accède effectivement au matériel. Seule cette petite partie nécessite donc des privilèges et effectue des appels système. Le reste du système d'exploitation peut être programmé en mode utilisateur, « au dessus » de cette partie. Par exemple, le micro noyau offrira la possibilité de charger un nouveau processus, mais l'ordonnanceur (qui choisit quel processus devra être chargé) ne fera pas partie du micro-noyau. On parle parfois de ''services'' / ''serveurs'' au dessus du micro-noyau.
Ceci permet d'avoir un noyau bas niveau beaucoup plus petit. Bien que ceci soit une bonne idée, et que les micro-noyaux puissent fournir de meilleurs garanties de sécurité, peu de noyaux sont effectivement des micro-noyaux. Un des problèmes est qu'un tel micro-noyau est un peu plus lent que ses cousins monolithiques. La raison principale est que dans le cas d'un micro-noyau, un appel système nécessite en fait des communications inter-processus.
Andrew Tanenbaum est un fervent défenseur des micro-noyaux.

Une autre architecture possible est d'utiliser des couches successives, chacune avec des privilèges réduits. Le système Multics avait cette architecture.
Par exemple, dans le système THE (1965), les couches étaient les suivantes :
# noyau bas niveau, multiprogrammation
# allocation de la mémoire pour les processus
# IPC (communication inter processus)
# entrées / sorties (buffer, etc.)
# programmes utilisateurs (compilation, exécution, ...)
# utilisateur (Dijkstra a annoté la description de cette couche par ''« not implemented by us »'')

Une dernière catégorie de noyau est la catégorie des machines virtuelles. Ces noyaux sont un peu à part, car il s'agit d'émuler un système d'exploitation ou du matériel particulier à l'intérieur d'un autre système d'exploitation ou matériel. Le mode noyau de la machine virtuelle est en fait dans le mode utilisateur du noyau original...

==Les processus==

===Introduction===

Allez hop commençons par une petite définition du type wikipédia :

Un processus (en anglais, process), en informatique, est défini par :
* un ensemble d'instructions à exécuter (un programme) ;
* un espace mémoire pour les données de travail ;
* éventuellement, d'autres ressources, comme des descripteurs de fichiers, des ports réseau, etc.

Un ordinateur équipé d'un système d'exploitation à temps partagé est capable d'exécuter plusieurs processus de façon « quasi- simultanée ». Par analogie avec les télécommunications, on nomme multiplexage (A. Tanenbaum parle de ''multiprogrammation'') ce procédé. S'il y a plusieurs processeurs, le système essaie de répartir les processus de manière équitable sur les processeurs disponibles.

Le processus doit être imaginé comme quelque chose qui prend du temps, donc qui a un début et (parfois) une fin. De nombreux processus ne se terminent normalement jamais : système d'exploitation, serveurs web, serveurs mail, ... D'autres processus plus légers qui ne se terminent pas sont les ''daemon'' (acronyme ''a posteriori'' de "disk and execution monitor") du monde Unix.

Certains processus sont démarrés très tôt lors de la séquence de boot. Le système d'exploitation est un tel processus. Sinon, les processus sont normalement démarrés grâce à un appel système à partir d'un autre processus. L'utilisateur peut par exemple demander explicitement un nouveau processus (sous POSIX, grâce à un <tt>fork</tt> puis <tt>exec</tt>) ; mais la plupart du temps, il le fera à travers une application, par exemple en double-cliquant sur l'icône d'un programme dans l'explorateur de fichiers.

Le système d'exploitation est chargé d'allouer les ressources (mémoires, temps processeur, entrées/sorties) nécessaires aux processus et d'assurer que le fonctionnement d'un processus n'interfère pas avec celui des autres (isolation).

Pas sûr d'avoir tout compris ? Ce n'est pas grave, essayons autrement.
:'''Définition :''' un processus est un programme en train de s'exécuter.
Cette définition implique en particulier que un programme (navigateur Firefox par exemple) peut correspondre à
* zéro processus si on ne l'a pas lancé,
* un processus si on l'a lancé,
* plusieurs processus si on l'a lancé plusieurs fois.
(''Remarque :'' pour un programme comme Firefox, il y a fort à parier que l'exécution d'une seule instance de Firefox génère de multiples sous-processus...)

Que se passe-t-il quand je démarre une application?

:L'ordinateur à une nouvelle tâche à accomplir, les instructions correspondantes sont donc envoyées au processeur. Comme il a plusieurs choses à faire le choix des instructions à exécuter n'est pas forcement simple. Il faut faire en sorte de partager le processeur entre les différentes tâches de manière équitable : c'est la fameuse gestion des processus.
:Ceci permet de réaliser plusieurs activités en ~même temps~. Grâce à la gestion des processus on peut regarder un film (obtenu par des moyens tout à fait légaux cela va de soit), tout en jouant à la dame de pique.
:(et dire que certain(e)s affirment que l'homme est mono tâche)

Plusieurs processus indépendants peuvent être ''actifs'' en même temps, mais sauf si l'ordinateur possède suffisamment de processeurs, on ne peut pas les exécuter simultanément. L'impression que plusieurs programmes s'exécutent ''en même temps'' vient simplement du fait que le processeur alterne rapidement entre eux.
Comme le temps d'exécution d'une instruction par le processeur est très court, de l'ordre de la nano-seconde, le processeur peut réaliser plusieurs centaines de millions d'instructions par seconde. Ainsi, une tranche de temps de quelques fractions de seconde, partagée entre plusieurs processus, donne à l'échelle macroscopique l'illusion de la simultanéité.

'''En résumé :''' un système d'exploitation doit la plupart du temps traiter plusieurs tâches en même temps, et comme il n'a, en général, qu'un seul processeur, il devra contourner ce problème grâce à un pseudo-parallélisme. Il traite une tâche à la fois, s'interrompt et passe à la suivante. La commutation de tâches étant très rapide, il donne l'illusion d'effectuer un traitement simultané.

===La table des processus===

L'information sur les processus est conservé par le système dans une structure de données appelée ''table des processus''. Cette table contient toutes les informations nécessaires à la gestion des processus :
* état du processus
* PID
* droits
* répertoire de travail
* pointeur vers la pile
* priorités
* ...

Sous Linux, on peut accéder à ces informations à travers le système de fichiers virtuel "Procfs". Il suffit d'aller dans le répertoire <tt>/proc/</tt>.

===Création d'un processus===

Pour les système POSIX, la création d'un processus est très simple : on utilise la fonction <tt>fork()</tt>. En C, le prototype de la fonction se trouve dans le fichier d'entêtes <tt>unistd.h</tt>.

Cette fonction prend 0 argument et permet de faire la chose suivante : elle crée un nouveau processus qui est une copie conforme du processus appelant. La seule différence visible entre l'ancien et le nouveau processus est que les processus ont un numéro (PID) différent. Pour le processus appelant, il peut obtenir le PID du nouveau processus en regardant la valeur de retour de <tt>fork</tt>. Pour le nouveau processus, cette valeur vaudra 0, et il devra utiliser la fonction <tt>getpid()</tt> pour obtenir son numéro.

Le processus appelant est appelé le ''père'' alors que le nouveau processus est appelé le ''fils''.

Notez que l'espace mémoire du processus est dupliqué plutôt que partagé. Ceci veut dire que les processus ne peuvent pas communiquer en utilisant leur variables... Par contre, les descripteurs de fichiers du fils sont hérités directement de ceux du père ; ils peuvent donc essayer de communiquer en passant par ces fichiers. (Mais cela pose de nombreux problèmes de synchronisation.)

Voici par exemple un petit programme C qui lance un processus fils:
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {

int pid ;
int pid_fils ;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
} else {
printf(" >> Je suis le fils.\n");
}

return(0);

}
Après compilation, voici un exemple d'exécution du programme résultant :
$ ./pere_fils
> Le processus 8248 démarre...
>> Je suis le fils.
>> Je suis le père (pid du fils = 8249).

Voici un autre exemple d'exécution :
$ ./pere_fils
> Le processus 8269 démarre...
>> Je suis le père (pid du fils = 8270).
>> Je suis le fils.

Notez que les numéros sont différents, et que l'ordre d'affichage n'est pas le même. Cela vient de l'ordonnancement des deux processus qui peut différer.

La technique consistant à faire
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
...
}
montre que malgré le fait que les processus soient identiques à l'origine, on peut faire beaucoup de chose.

:'''Remarque :''' <tt>fork()</tt> n'est pas directement un appel système, mais une fonction qui utilise l'appel système <tt>clone()</tt>. Cet appel système ne fait pas partie de la norme POSIX...

La deuxième technique utilisée dans les systèmes POSIX consiste à utiliser <tt>fork()</tt> pour dupliquer le processus, puis à complètement remplacer le fils par un nouveau processus. La fonction correspondante est la fonction <tt>execv</tt> :
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
execv("/usr/bin/...", argv);
...
}
La fonction <tt>execv</tt> prend 2 arguments : une chaîne contenant le chemin d'accès à un programme, et un tableau d'arguments à donner au programme. (C'est un peu plus compliqué que ça : le premier élément du tableau est le nom du programme, et le tableau doit se terminer par un pointeur NULL.)

Une dernière fonction importante est la fonction <tt>wait(pid)</tt> qui permet à un processus d'attendre l'arrêt du processus <tt>pid</tt>.

-- ...

L'API WIN32 possède de nombreuses fonctions avec des fonctionnalités similaires. Par exemple, la fonction [http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx <tt>CreateProcess</tt>] permet de créer un nouveau processus (comme un <tt>fork</tt> suivi d'un <tt>exec</tt>), mais elle nécessite ... 10 arguments !

----

Un autre moyen de créer des processus est d'utiliser des 'processus légers' appelés Thread. Ces processus légers partage seulement une partie de la mémoire, ce qui en pratique est plus rapide pour simuler un parallélisme. On passe alors par une autre fonction. Sous GNU/Linux, lors de l'écriture d'un programme écrit en C il faut utiliser la bibliothèque pthread.h et lors de la compilation, faire un lien vers celle ci, en utilisant le paramètre -lpthread.

====Arborescence des processus dans les systèmes POSIX====

Nous avons vu que la fonction <tt>fork()</tt> permet de créer un processus fils. Le père connaît le PID de son fils : il lui est donné par la fonction <tt>fork()</tt>. Comme le fils peut lui même créer des processus fils, on obtient rapidement une arborescence de processus.

Vous pouvez visualiser cette arborescence à partir d'un terminal avec la commande <tt>pstree</tt> (l'option <tt>-p</tt> permet de demander l'affichage des PID)
$ pstree -p
init(1)─┬─acpid(25425)
├─atd(14365)
├─console-kit-dae(3632)─┬─{console-kit-dae}(3633)
│ ├─{console-kit-dae}(3641)
...
├─cron(14315)
├─dbus-daemon(15590)
├─dbus-daemon(3511)
...
├─getty(4095)
├─getty(4096)
├─getty(4097)
├─getty(4098)
├─getty(4099)
├─gpm(3528)
...
├─kded4(15769)
├─kdeinit4(15766)───klauncher(15767)
├─kdm(15564)─┬─Xorg(15566)
│ └─kdm(15573)───sh(15608)─┬─conky(15751)
│ ├─fluxbox(15703)───firefox-bin(6063)─┬─{firefox-bin}(6064)
│ │ ├─{firefox-bin}(6065)
...
│ ├─ssh-agent(15698)
│ ├─unclutter(15742)
│ ├─wicd-client(15749)
│ └─xscreensaver(15683)
...
├─rsyslogd(6850)─┬─{rsyslogd}(6140)
│ └─{rsyslogd}(6141)
├─screen(4427)─┬─bash(4428)───pstree(9307)
│ ├─bash(4429)───man(7952)───pager(7965)
│ ├─bash(4430)───vi(30568)
│ ├─bash(18395)───vi(28512)
│ └─mutt(8763)
...

Le processus <tt>init</tt> est l'ancêtre de tout les processus, il a toujours 1 comme PID.

'''Remarque :''' sous Windows, les processus ne sont pas organisé en arborescence...

====Mort d'un processus dans un système POSIX====

Un processus peut se terminer pour plusieurs raisons :
* volontairement, grâce à la fonction <tt>exit()</tt> (POSIX) ou <tt>ExitProcess()</tt> (Windows),
* à cause d'une erreur,
* en recevant un signal d'un autre processus, grâce à la fonction <tt>kill()</tt> (POSIX) ou <tt>TerminateProcess()</tt> (Windows).

Lorsqu'un processus se termine, plusieurs choix sont possibles :
* que fait-on de ses fils ?
* que fait-on de son père ?

Linux fait la chose suivante : quand un processus s'arrête,
* tous ces fils s'arrêtent,
* son père reçoit un signal le prévenant que son fils vient de mourir.

Pour que le père puisse recevoir le signal correspondant, il faut qu'il utilise la fonction <tt>wait()</tt> ou <tt>waitpid()</tt>. Tant que le parent existe et qu'il n'a pas reçu le signal disant qu'un de ces fils est mort, le processus fils n'est pas entièrement supprimé : il devient un ''zombie''. (Il n'occupe plus vraiment de place en mémoire, mais le système garde juste suffisamment d'information pour pouvoir prévenir le père si celui ci demande l'état du fils.)

'''Remarque :''' les processus Windows ne sont pas organisés sous forme d'arborescence. Chaque processus peut surveiller l'état d'un autre processus, s'il connaît son PID. Il n'y a donc pas de notion de processus ''zombie'' sous Windows.

Voici un petit programme C qui crée un processus fils, ne fait rien pendant 20 secondes, puis demande l'état de son fils :
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
int pid ;
int pid_fils ;
int w;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
printf(" >> Je suis le père et j'attends un peu.\n");
sleep(20);
printf(" >> Je suis le père et je demande l'état de mon fils.\n");
wait(&w);
printf(" >> Mon fils est mort (signal %i).\n", w);
while(1) sleep(1);
} else {
printf(" >> Je suis le fils.\n");
while (1) sleep(1);
exit(0);
}
return(0);
}
Si on tue le processus fils pendant que le père ne fait rien, le processus fils devient un zombie. Dès que le père fait le <tt>wait</tt>, il reçoit la valeur du signal qui a terminé le processus et le zombie disparaît.

Si on ne tue pas le processus fils, le père n'exécutera jamais le <tt>printf(" >> Mon fils est mort...);</tt>.

'''Remarque :''' dans un système POSIX, lorsqu'un processus meurt, ses fils deviennent ''orphelins''. Il continuent leur exécution mais sont adopté par <tt>init</tt> (PID : 1). Dans certains cas lorsque le processus est arrêté, il envoie explicitement un signal <tt>SIGTERM</tt> pour tuer ses processus fils. C'est par exemple ce qui arrive lorsqu'on lance des application à partir d'un terminal et que l'on quitte le terminal en question...

===États d'un processus===

On peut imaginer un SE dans lequel les processus pourraient être dans trois états :
* en cours d'exécution,
*bloqué : il attend un événement extérieur pour pouvoir continuer (par exemple une ressource; lorsque la ressource est disponible, il passe à l'état "prêt")
*prêt : suspendu provisoirement pour permettre l'exécution d'un autre processus.

Dans un système avec un unique processeur, au plus un processus peut se trouver dans l'état ''en cours d'exécution''. Par contre, il peut y avoir de nombreux processus dans l'état ''bloqué'' ou dans l'état ''prêt''.

Un processus peut passer d'un état à l'autre :
# de ''en exécution'' à ''bloqué'' lorsqu'une ressource n'est pas disponible (entrées / sortie par exemple),
# de ''bloqué'' à ''prêt'' si la ressource ayant provoqué le blocage devient disponible,
# de ''en exécution'' à ''prêt'' si le système décide de suspendre l'exécution du processus,
# de ''prêt'' à ''en exécution'' si le système décide de lancer l'exécution du processus.

On peut résumer ceci par le graphe de transitions suivant :

[[Image:Diagrammedétatdunprocessus.png]]

Les transition manquantes ne sont pas possible directement mais doivent passer par des transition intermédiaires.

On peut ajouter 2 états :
* ''nouveau'' pour un processus qui vient d'être créé,
* ''terminé'' pour un processus qui vient de se terminé.

Dans les systèmes type ''ordinateur de bureau'', le passage de ''nouveau'' à ''prêt'' est automatique mais dans des systèmes temps réel, un processus peut parfois attendre dans cet état.

L'état ''terminé'' est en général passager. Par exemple, lorsqu'un processus terminé est un zombie, le processus n'est conservé que dans la table des processus. La mémoire utilisé par le processus est libérée. La question de savoir si ceci est véritablement un état du processus est donc essentiellement une question de vocabulaire.

:exercice : ajouter les états ''nouveau'' et ''terminé'' et les transitions correspondantes au graphe précédent. Identifiez des situations provoquant les transitions possibles entre états.

===Ordonnancement des processus===

Nous avons vu qu'il pouvait y avoir de nombreux processus dans la table de processus (environ 150 sur mon ordinateur en ce moment même). Parmi ces processus, un seul (sur une machine à un processeur) peut se trouver dans l'état ''en exécution''. C'est au système d'exploitation de décider qui, à un moment donnée, doit se trouver dans cet état. La partie du système faisant ceci s'appelle ''ordonnanceur'' (ou ''scheduler'' en anglais).
En utilisant le contenu de la table des processus et éventuellement d'autres information, ordonnanceur doit donc gérer les transition entre états de tous les processus, et envoyer l'information nécessaire aux composants adéquat du noyau.

Comme d'habitude, l'ordonnanceur doit faire des compromis entre :
* la vitesse,
* l'utilisation de la mémoire,
* l'optimalité de la solution proposée.

'''Remarque : ''' l'ordonnanceur est lui même un processus (ou un morceau de processus dans le cas des noyaux monolithiques).

====Ordonnancement non préemptif====

'''FIFO.'''
L'algorithme d'ordonnancement le plus facile est probablement celui de type ''FIFO'' : premier arrivé, premier servi. Autrement dit, on préempte premier processus arrivé, et on l'exécute jusqu'à la fin. La seul structure de donnée est donc simplement une ''file''.

'''Plus court temps d'exécution.'''
Dans certain cas, on peut prévoir a l'avance le temps processeur dont aura besoin un processus pour s'exécuter. On peut alors choisir le processus le plus court et l'exécuter en premier. Ceci a en général tendance à diminuer le temps d'attente moyen d'un processus ; mais si des processus courts sont crées régulièrement, on peut assister à une ''famine'' : un processus peut ne jamais s'exécuter.

:exercice : trouver une suite de processus qui provoque une famine.

Ces deux exemples sont acceptables pour un ''traitement par lots'' (batch) par exemple pour des calculs numériques. Ils ne sont par contre pas du tout adaptés pour un ordinateur personnel ou un système temps réels. (Pas de ''multiprogrammation''.)

====Ordonnancement préemptif====

Pour pouvoir donner l'illusion de simultanéité, les processus sont en général exécutés par tranches de temps spécifiées à l'avance (''time slice'' en anglais). Au bout de ce temps, le noyau reçoit une interruption et examine les processus. Il peut décider de continuer le processus courant, ou bien le remplacer par un autre processus. on parle de préemption.

Windows 3.1 ou MacOS 9 étaient des systèmes ''collaboratifs'' car les processus devaient explicitement laisser la main aux autres processus. Tous les systèmes d'exploitation modernes sont maintenant préemptifs. On parle maintenant de système préemptif lorsque la préemption peut s'effectuer même sur des processus en mode noyau.
On parle parfois de noyau préemptible lorsque que les opérations en mode noyau sont elle même préemptibles.

'''Tourniquet.'''
L'algorithme le plus simple est probablement celui du tourniquet (''round Robin'' en anglais). C'est une variante de l'algorithme FIFO vu plus haut, mais qui préempte le processus courant au bout d'un moment. Si ce processus est encore en exécution, on le remet à la fin de la file des processus.

Le temps imparti à chaque processus ne doit pas être trop court (sinon, le changement de contexte prend trop de temps par rapport à l'exécution des processus) ni trop long (sinon, on perd l'illusion de parallélisme, et un processus bloqué risque d'occuper le processeur pendant trop longtemps).

Voici ce qu'on peut trouver dans le livre "Understanding the Linux kernel" :

<cite>
The choice of quantum duration is always a compromise. The rule of thumb adopted by Linux is: choose a duration as long as possible, while keeping good system response time.
</cite>

(extrait du chapitre [http://oreilly.com/catalog/linuxkernel/chapter/ch10.html "Process Scheduling"]).

'''Tourniquet avec priorité.'''
Tous les processus ne naissent pas égaux : certains ont une importance plus élevée (les processus systèmes par exemple). Dans un cas comme le précédent, tous les processus ont le même statut...
Pour corriger ce problème, on utilise parfois un algorithme similaire, mais on choisit le premier processus de priorité la plus élevé possible. Plutôt que de parcourir la file à sa rechercher, on utilise en fait plusieurs files : une pour chaque priorité.

Il faut faire attention car les processus de priorité basse risquent de ne jamais être exécutés (famine)... Par exemple, on peut diminuer petit à petit la priorité des processus qu'on exécute...

Une autre solution pour gérer les priorité en évitant certaines famines est d'exécuter toutes les files, mais pas en proportion égale. Par exemple, on choisit un processus dans les piles de priorité 1, 2, 1, 3, 1, 2, 1, 4, 1, 2, 1, 3, 1, 2, 1, ... De cette manière, les processus de la première file sont exécutés 2 fois plus de fois que ceux de la file 2, et 4 fois plus de fois que ceux de la file 3.

:exercice : donnez un algorithme pour générer la suite précédente pour un nombre donné de files. Il faut que la file ''i'' soit utilisée 2 fois plus souvent que la pile ''i+1''.

'''Répartition garantie.'''
Chaque tache reçoit la même proportion du processeur, et chaque utilisateur reçoit la même proportion également.

'''tirage aléatoire.'''
À chaque étape, on tire un "billet" au hasard, et le processus qui a le "billet gagnant" s'exécute.

Principe de priorité : Les processus qui ont été définit comme prioritaire on plus de "billet" à leur nom et ont donc plus de chance d'être tiré.

''NB : POSIX définit une commande "nice" qui permet e donner à un processus un priorité plus faible (et par conséquent, nice -x augmente cette priorité). Il est évident que tout le monde ne doit pas pouvoir utiliser cette commande, il vaut mieux que l'administrateur se réserve ce droit''

'''Ordonnancement équitable.'''

==La mémoire==

===Introduction===

RAM = Random Acces Memory. C'est ce que l'on appelle couramment la mémoire vive, elle peut être modifié à l'infini et sert à stocker temporairement les fichiers que l'ordinateur exécute.

ROM = Read Only Memory. On l'appelle aussi mémoire fixe ou mémoire morte, dès que l'on enregistre, le contenu d'une mémoire ROM ne peut pas être modifié (ex: un CD-ROM).

'''Gestion de la mémoire : '''

Lors du boot du PC, le système est chargé en mémoire.
Tout processus créé est aussi chargé dans la mémoire.

Lorsque l'on créé uns seul processus, il est plus pratique de le charger en "bas" de la mémoire, à partir de la première case de l'espace mémoire. Puis les nouveaux processus peuvent être charger par dessus. Ainsi la machine comprend où commence l'espace mémoire.

Problèmes :
1 - l'espace d'adressage ne commence pas à 0;
2 - un processus peut demander dynamiquement de la mémoire;
3 - avec un accès direct, un processus peut faire "planter" un autre.

==> Il faut avoir une couche d'abstraction au-dessus de la mémoire physique.

===Espaces d'adressage===

Et si l'on créait des espaces d'adressage distincts pour chaque processus ?
Par exemple : chaque processus utilise des adresse de 0 à n de la mémoire, on converti alors ces adresses en adresses physiques.

Certains des premiers processeurs avaient deux registres supérieurs :

- une Base => adresse physique du début de l'espace d'adressage

- une Limite => adresse physique de fin de l'espace d'adressage

Par exemple, lors de l'exécution d'un processus l'accès à une case "a" se transforme en l'accès à la Base+a et un test pour vérifier que : a+Base < Limite.

Malgré tout, ceci ne résout pas les problèmes liés au fait que des processus sont créés et disparaissent, réclament ou libèrent de la mémoire.

===Va-et-vient (swapping)===

====Idée====

Et si pour gérer tout cela on utilisait une mémoire auxiliaire (disque), pour stocker l'état de la mémoire de processus.

La mémoire vue par les processus ne correspond pas à la mémoire physique. À un instant donné, certains processus peuvent se retrouver sur le disque (dans le SWAP).

Quand un processus apparait, on lui cherche un morceau d'espace libre dans la mémoire.

====gestion de la mémoire====

* tableau de bits
* liste chaînée

====Allocation====

* first fit
* next fit
* best fit
* worst fit

===Mémoire virtuelle===

====Idée====

====Pagination====

====Traduction des adresses====

====Table des pages====

====Table inversée====

====Remplacement des pages====

==Les entrées / sorties==

----
----

==Références==

* le livre « Systèmes d'exploitation » de Andrew Tanenbaum est disponible à la BU
* la page du [http://sos.enix.org/fr/PagePrincipale projet SOS]
* la [http://www.opengroup.org/onlinepubs/009695399/nfindex.html norme POSIX:2004]
* l'[http://msdn.microsoft.com/en-us/library/aa383749(VS.85).aspx API win32]
* [http://www.lemis.com/grog/Documentation/Lions/index.php Commentary on the Sixth Edition UNIX Operating System]

INFO502 : Systèmes d'exploitation

2009-12-10T08:38:07Z

Hatat : /* TP */ Lien Multiboot

Ce wiki est un complément de cours pour le cours « info-502 : systèmes d'exploitation ». La participation au wiki est fortement encouragée.

Pour pouvoir modifier les pages, inscrivez-vous (lien en haut à droite) pour obtenir un login et mot de passe. (Choisissez un login du style ''PrenomNom''...)

Je vous conseille d'aller lire [http://meta.wikimedia.org/wiki/Aide:Contenu ce guide] pour vous familiariser avec les wikis.

Exercice : si vous n'en avez pas, créez-vous un compte et essayez de modifier cette page (correction de fautes d'hortographe, rajout de détails, mise en page, ...)

Vous pouvez aussi utiliser la page de discussion pour ... discuter. (Ou poser des questions, faire des commentaires etc.)

----
----
==Auteur du cours==

===Nouvelles===

===Supports===

====TD====

Sujets de TD :
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td1.pdf Ordonnancement],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td2.pdf Gestion de la mémoire],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td3.pdf Systèmes de fichiers].

====TP====

# Découverte de SOS :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp1.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp1.tar.gz code source],
#* [http://www.gnu.org/software/grub/manual/multiboot/multiboot.html Multiboot Specification] : SOS respecte la spécification Multiboot, qui dit comment un système d'exploitation doit être chargé en mémoire par GRUB (ou tout autre chargeur respectant cette spécification).
# Gestion de la mémoire du noyau :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp2.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp2.tar.gz code source],
#* Article [http://sos.enix.org/wiki-fr/upload/SOSDownload/sos-texte-art5.pdf Gestion de la mémoire virtuelle du noyau].
# Ordonnancement.

==Introduction==

-- ...

==Repères historiques==

Voici quelques évènements clés dans l'histoire des systèmes d'exploitation. Pour plus de détails, ou pour des compléments sur l'histoire de l'informatique, je vous renvoie sur Wikipedia : [http://en.wikipedia.org/wiki/History_of_operating_systems "History of operating systems"] et [http://en.wikipedia.org/wiki/History_of_computing "History of computing"].

Les premiers ordinateurs ne comportaient pas vraiment de système d'exploitation : c'étaient des opérateurs humains qui géraient tout. (C'était juste après la seconde guerre mondiale, l faut savoir que les langages de programmation n'existaient même pas...) La petite histoire (??) raconte qu'à un moment, les processus pour l'ordinateur de l'université de Cambridge étaient accrochés sur une corde à linge et que c'était la couleur des pinces à linges qui donnait la priorité. (??)

Le passage à la notion de système d'exploitation c'est faite graduellement pour répondre à la complexité de plus en plus grande des ordinateurs et aux demandes des utilisateurs.

Les premier systèmes d'exploitation datent probablement de 1956. Ils permettaient simplement d'exécuter un nouveau programme lorsque le précédent était terminé. Les ordinateurs d'IBM de la famille System/360 ont ensuite eu toute une série de systèmes d'exploitation plus ou moins similaires : OS/360, DOS/360 (rien à voir avec MS-DOS), TSS/360... C'est à cette époque qu'est apparu la notion de multiprogrammation (possibilité d'avoir plusieurs processus entrelacés.)
C'est également au début des années 60 qu'on a commencé à voir des systèmes avec temps partagé : plusieurs utilisateurs pouvaient utiliser un ordinateur. Le système Multics a été, à ce niveau comme à d'autres, assez révolutionnaire. Multics a été utilisé jusqu'en 2000 !

Multics n'était par contre pas approprié pour les mini-ordinateurs où le nombre d'utilisateur est relativement restreint. En 1969, Ken Thomson
a développé une variante simplifié de Multix : Unix...

Ce n'est qu'un peu plus tard (1979) que la première version de DOS (86-DOS ou QDOS) apparaît. 86-DOS sera racheté par Microsoft un 1980...

'''Liens et compléments :'''
* [http://en.wikipedia.org/wiki/Timeline_of_operating_systems Timeline of operating systems]
* généalogie des systèmes Unix : [http://www.levenez.com/unix/ Unix History]
* généalogie de Windows : [http://www.levenez.com/windows/ Windows History]
* généalogie des systèmes non-Unix : [http://www.oshistory.net/metadot/index.pl?id=2165 timeline of non-Unix operating systems]

==Vue d'ensemble==

Ce cours reste assez généraliste et essaie de regarder les principales fonction d'un système d'exploitation. Les systèmes de type Unix (Linux) sera un exemple privilégié. À cause de leur complexité intrinsèque, les évolutions modernes (architectures multicoeur ou multiprocesseur, ...) seront en partie ignorée dans un premier temps.

Les problèmes fins de communication entres processus ne seront que très peu abordés, car ils font l'objet d'un cours séparé (info604) pour la filière info.

Nous allons suivre l'ordre classique consistant à regarder :
# les processus
# la mémoire
# les entrées / sorties

La fin du cours dépendra du temps restant...

===Les processus===

Un processus est simplement un programme « en exécution ». À tout instant, un ordinateur de bureau contemporain contient de nombreux processus qui doivent partager le (les) processeur(s) pour donner l'impression qu'ils s'exécutent « en même temps ». Un des rôles du système d'exploitation consiste à décider dans quel ordre les processus vont effectivement pouvoir utiliser le processus.

===La mémoire===

La mémoire est, comme le processeur, une ressource partagée par les différents processus. Il faut donc gérer la quantité de mémoire allouée et utilisée pour que les processus n'aient pas à s'occuper de ceci. Un des concepts fondamentaux est celui de mémoire virtuelle. Ceci permet d'offrir un espace mémoire pour chacun des processus de manière transparente.

===Les entrées / sorties===

Un ordinateur n'est pas (plus) un système indépendant du reste du monde : il interagit avec l'extérieur à travers des périphériques d'entrées/sorties (clavier / écran / souris / ...). La gestion de ces périphériques pose un ensemble de problèmes que nous aborderons brièvement...

===...===

Une fois ces notions vues, nous regarderons peut-être les problèmes de sécurité, de multimédia ou des architectures multiprocesseurs.

==Préliminaires==

===Quoi ?===

Les ordinateurs, ou plus simplement les micro contrôleurs sont des circuits électroniques avec une puce « processeur ». Le développement d'applications n'est pas facile si on se place au niveau électronique et que l'on parle directement au CPU. Pour faciliter la vie des programmeurs, plusieurs couches d'abstraction sont nécessaires. La première se place au niveau matériel et s'occupe directement des problèmes électroniques ou de très bas niveau. Il s'agit du ''firmware''. Il répond par exemple aux questions comme :
* qu'elle est l'amplitude des signaux envoyés par l'horloge ?
* est-ce que l'UC possède un pipeline ?
* ...
Un firmware est donc forcement très lié au matériel sur lequel il tourne.

La couche suivante est le système d'exploitation à proprement parler. Dans le cas que vous connaissez le mieux (ordinateur personnel), le système d'exploitation fournit une interface pour :
* exécuter un programme
* exécuter plusieurs programmes « en même temps »
* gérer les ressources (temps processeur, mémoire disponible, entrées / sorties)
* les opérations sur les fichiers
* offrir des garanties de sécurité

===Où ?===

On trouve des systèmes d'exploitation partout :

* dans les ordinateurs personnels (Linux, BSD, MacOS, Solaris, Windows, ChromeOS (?))
* dans les PDA (PalmOS, ...)
* dans les téléphones portables (Android, OpenMoko,Symbian,)
* console de jeux
* lecteur MP3 (Rockbox, ...)
* les microcontroleurs « avancés »

===Comment ?===

====Langage de programmation====

Le système d'exploitation se situe entre le firmware (très bas niveau) et l'utilisateur. La nécessité d'accéder à ces ressources de très bas niveau implique que les langages de haut niveaux (Java, Ada, Python, ...) ne sont pas du tout adaptés à l'écriture des systèmes d'exploitation.
Le langage le plus utilisé reste à ce jours le langage C : Linux, BSD, MacOS, Windows, ... sont tous écrits pour leur plus grande partie en C.

Vous avez normalement un cours de C en parallèle, et les TPs utiliseront le langage C. (La référence sur le langage C reste à mon goût le livre de Kernighan et Ritchie : « the C Programming language ». (Disponible en francais à la BU sous le titre « Le langage C : norme Ansi ».) Il existe de nombreux autres livres / documents sur la programmation C comme le [http://www-clips.imag.fr/commun/bernard.cassagne/Introduction_ANSI_C.html polycopié de Bernard Cassagne « introduction au langage C »].

Les premiers systèmes d'exploitation étaient écrits directement en langage machine, ou bien en langage d'assembleur ; et les systèmes actuels comportent encore quelques parties de très bas niveau en langage d'assemblage...

====Notion d'appel système, norme POSIX====

La programmation de haut niveau en C est assez différente de la programmation système. De nombreuses fonctions C utilisent en fait des « appels système », c'est à dire des appels de fonctionnalités propres du système d'exploitation. Les appels système typiques sont :
* les fonctions relatives aux fichiers (création, suppression, modification...)
* les fonctions relatives à la gestion de la mémoire
* les fonctions relatives aux processus (<tt>fork</tt>)
* ...

De nombreux système d'exploitation proposent une interface [http://en.wikipedia.org/wiki/Posix POSIX] (« '''P'''ortable '''O'''perating '''S'''ystem '''I'''nterface for Uni'''x''' »). Cette norme définit entre autres un ensemble de fonctions pour utiliser les appels systèmes.
Le nombre de ces fonctions est relativement faible : une centaine ; et chacune correspond en gros à un appel système. Certaines de ces fonctions ne sont pas définies directement dans le système d'exploitation, mais dans des librairies. Pour Linux, il s'agit en général de la librairie Glibc (GNU C Library).

Par exemple, la fonction <tt>open</tt> (qui permet d'ouvrir un fichier) correspond exactement à un appel système ; alors que la fonction <tt>malloc</tt> (qui permet d'allouer dynamiquement de la mémoire dans le tas) peut générer plusieurs appels système (<tt>brk</tt> et <tt>sbrk</tt>).

Pour visualiser les appels systèmes effectués par un programme sous Linux, vous pouvez utilisez l'utilitaire <tt>strace</tt> ou <tt>ltrace</tt>. Par exemple, dans le shell :
$ strace -e trace=file ls -l 2> trace
permet de récupérer tous les appels systèmes relatifs aux fichiers lors de l'appel à <tt>ls -l</tt>. La liste des appels système est redirigée dans le fichier <tt>trace</tt> qui contiendra par exemple des lignes telles que
lstat64("Desktop", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lgetxattr("Desktop", "security.selinux", 0x8cc08e0, 255) = -1 ENODATA (No data available)
dénotant ainsi un appel aux appels système <tt>lstat64</tt> et <tt>lgetxattr</tt>...

Les principaux systèmes compatibles POSIX sont :
* Linux
* BSD (et variantes)
* Mac OS X
* Solaris

De nombreux appels systèmes sont disponibles directement (sans avoir besoin d'écrire un programme C) à travers le shell. Exécuté dans un terminal, le shell permet, en première approximation, de passer directement des commandes au système d'exploitation. (La norme POSIX définit également un ensemble de fonctions du shell. Il est donc relativement aisé de changer de système d'exploitation tant qu'on reste dans les systèmes compatibles POSIX.)

Windows d'un autre côté utilise l'interface Win32 API, qui définit plusieurs milliers de fonctions. La plupart de ces fonctions peuvent utiliser plusieurs appels système...

Les systèmes d'exploitation qui utilisent l'API Win32 sont :
* Windows, depuis Windows95.

Il est possible d'installer un environnement compatible POSIX sur une machine Windows grâce à Cygwin. (C'est d'ailleurs fortement conseillé si vous ne voulez pas installer une version de Linux ou BSD sur votre ordinateur personnel...)

====Mode noyau / mode utilisateur====

La partie fondamentale du système d'exploitation est le ''noyau'' (''kernel'' en anglais). C'est la couche de plus bas niveau.

Les fonctionnalités de très bas niveau offertes par le noyau peuvent facilement planter l'ordinateur. Il faut donc une politique de restriction pour que tous les programmes ne puissent y accéder dans leur totalité. On parle de
* mode noyau
* mode utilisateur

Dans le mode utilisateur, on ne peut accéder à ces fonctionnalités qu'a travers les appels systèmes ; dans le mode noyau, on peut tout faire... Bien entendu, un appel système doit passer momentanément en mode noyau pour pouvoir exécuter les commandes pertinentes, puis il repasse automatiquement en mode utilisateur.

La définition d'un appel système pourrait donc être « fonctionnalité atomique nécessitant un passage en mode noyau ».

====Noyau, noyau monolithique, micro-noyau====

La partie principale du système d'exploitation. C'est lui qui gère les ressources, les entrées / sorties, la communication entre processus, ... Les deux architectures principales pour un noyau sont :
* noyau monolithique
* micro-noyau
La plupart des systèmes actuels sont basés sur un noyau monolithique (Linux, BSD, Mac OS X, Solaris, Windows).

Les noyaux monolithiques sont parfois décrits comme « sans vraie structure » : une grosse soupe où cohabitent toutes les fonctionnalités du système d'exploitation. L'idée d'avoir un système unique qui gère tout est effectivement peu attirante et peut poser quelques problèmes de génie logiciel...
Un noyau monolithique est donc la couche entre le matériel et les programmes utilisateurs. Pour éviter de compiler des noyaux énormes, les noyaux monolithiques actuels utilisent en plus la notion de ''module''. Ce sont des morceaux du noyau qu'on peut charger ou décharger au besoin. Si l'interface est connue, ces modules peuvent éventuellement être en binaire, ce qui permet d'utiliser des modules propriétaires avec un noyau libre.
Sous Linux, la commande
$ lsmod
permet d'obtenir la liste des modules chargés dans le noyau.

Les micro-noyaux d'un autre coté sont basés sur la remarque que seule une toute petite partie du noyau accède effectivement au matériel. Seule cette petite partie nécessite donc des privilèges et effectue des appels système. Le reste du système d'exploitation peut être programmé en mode utilisateur, « au dessus » de cette partie. Par exemple, le micro noyau offrira la possibilité de charger un nouveau processus, mais l'ordonnanceur (qui choisit quel processus devra être chargé) ne fera pas partie du micro-noyau. On parle parfois de ''services'' / ''serveurs'' au dessus du micro-noyau.
Ceci permet d'avoir un noyau bas niveau beaucoup plus petit. Bien que ceci soit une bonne idée, et que les micro-noyaux puissent fournir de meilleurs garanties de sécurité, peu de noyaux sont effectivement des micro-noyaux. Un des problèmes est qu'un tel micro-noyau est un peu plus lent que ses cousins monolithiques. La raison principale est que dans le cas d'un micro-noyau, un appel système nécessite en fait des communications inter-processus.
Andrew Tanenbaum est un fervent défenseur des micro-noyaux.

Une autre architecture possible est d'utiliser des couches successives, chacune avec des privilèges réduits. Le système Multics avait cette architecture.
Par exemple, dans le système THE (1965), les couches étaient les suivantes :
# noyau bas niveau, multiprogrammation
# allocation de la mémoire pour les processus
# IPC (communication inter processus)
# entrées / sorties (buffer, etc.)
# programmes utilisateurs (compilation, exécution, ...)
# utilisateur (Dijkstra a annoté la description de cette couche par ''« not implemented by us »'')

Une dernière catégorie de noyau est la catégorie des machines virtuelles. Ces noyaux sont un peu à part, car il s'agit d'émuler un système d'exploitation ou du matériel particulier à l'intérieur d'un autre système d'exploitation ou matériel. Le mode noyau de la machine virtuelle est en fait dans le mode utilisateur du noyau original...

==Les processus==

===Introduction===

Allez hop commençons par une petite définition du type wikipédia :

Un processus (en anglais, process), en informatique, est défini par :
* un ensemble d'instructions à exécuter (un programme) ;
* un espace mémoire pour les données de travail ;
* éventuellement, d'autres ressources, comme des descripteurs de fichiers, des ports réseau, etc.

Un ordinateur équipé d'un système d'exploitation à temps partagé est capable d'exécuter plusieurs processus de façon « quasi- simultanée ». Par analogie avec les télécommunications, on nomme multiplexage (A. Tanenbaum parle de ''multiprogrammation'') ce procédé. S'il y a plusieurs processeurs, le système essaie de répartir les processus de manière équitable sur les processeurs disponibles.

Le processus doit être imaginé comme quelque chose qui prend du temps, donc qui a un début et (parfois) une fin. De nombreux processus ne se terminent normalement jamais : système d'exploitation, serveurs web, serveurs mail, ... D'autres processus plus légers qui ne se terminent pas sont les ''daemon'' (acronyme ''a posteriori'' de "disk and execution monitor") du monde Unix.

Certains processus sont démarrés très tôt lors de la séquence de boot. Le système d'exploitation est un tel processus. Sinon, les processus sont normalement démarrés grâce à un appel système à partir d'un autre processus. L'utilisateur peut par exemple demander explicitement un nouveau processus (sous POSIX, grâce à un <tt>fork</tt> puis <tt>exec</tt>) ; mais la plupart du temps, il le fera à travers une application, par exemple en double-cliquant sur l'icône d'un programme dans l'explorateur de fichiers.

Le système d'exploitation est chargé d'allouer les ressources (mémoires, temps processeur, entrées/sorties) nécessaires aux processus et d'assurer que le fonctionnement d'un processus n'interfère pas avec celui des autres (isolation).

Pas sûr d'avoir tout compris ? Ce n'est pas grave, essayons autrement.
:'''Définition :''' un processus est un programme en train de s'exécuter.
Cette définition implique en particulier que un programme (navigateur Firefox par exemple) peut correspondre à
* zéro processus si on ne l'a pas lancé,
* un processus si on l'a lancé,
* plusieurs processus si on l'a lancé plusieurs fois.
(''Remarque :'' pour un programme comme Firefox, il y a fort à parier que l'exécution d'une seule instance de Firefox génère de multiples sous-processus...)

Que se passe-t-il quand je démarre une application?

:L'ordinateur à une nouvelle tâche à accomplir, les instructions correspondantes sont donc envoyées au processeur. Comme il a plusieurs choses à faire le choix des instructions à exécuter n'est pas forcement simple. Il faut faire en sorte de partager le processeur entre les différentes tâches de manière équitable : c'est la fameuse gestion des processus.
:Ceci permet de réaliser plusieurs activités en ~même temps~. Grâce à la gestion des processus on peut regarder un film (obtenu par des moyens tout à fait légaux cela va de soit), tout en jouant à la dame de pique.
:(et dire que certain(e)s affirment que l'homme est mono tâche)

Plusieurs processus indépendants peuvent être ''actifs'' en même temps, mais sauf si l'ordinateur possède suffisamment de processeurs, on ne peut pas les exécuter simultanément. L'impression que plusieurs programmes s'exécutent ''en même temps'' vient simplement du fait que le processeur alterne rapidement entre eux.
Comme le temps d'exécution d'une instruction par le processeur est très court, de l'ordre de la nano-seconde, le processeur peut réaliser plusieurs centaines de millions d'instructions par seconde. Ainsi, une tranche de temps de quelques fractions de seconde, partagée entre plusieurs processus, donne à l'échelle macroscopique l'illusion de la simultanéité.

'''En résumé :''' un système d'exploitation doit la plupart du temps traiter plusieurs tâches en même temps, et comme il n'a, en général, qu'un seul processeur, il devra contourner ce problème grâce à un pseudo-parallélisme. Il traite une tâche à la fois, s'interrompt et passe à la suivante. La commutation de tâches étant très rapide, il donne l'illusion d'effectuer un traitement simultané.

===La table des processus===

L'information sur les processus est conservé par le système dans une structure de données appelée ''table des processus''. Cette table contient toutes les informations nécessaires à la gestion des processus :
* état du processus
* PID
* droits
* répertoire de travail
* pointeur vers la pile
* priorités
* ...

Sous Linux, on peut accéder à ces informations à travers le système de fichiers virtuel "Procfs". Il suffit d'aller dans le répertoire <tt>/proc/</tt>.

===Création d'un processus===

Pour les système POSIX, la création d'un processus est très simple : on utilise la fonction <tt>fork()</tt>. En C, le prototype de la fonction se trouve dans le fichier d'entêtes <tt>unistd.h</tt>.

Cette fonction prend 0 argument et permet de faire la chose suivante : elle crée un nouveau processus qui est une copie conforme du processus appelant. La seule différence visible entre l'ancien et le nouveau processus est que les processus ont un numéro (PID) différent. Pour le processus appelant, il peut obtenir le PID du nouveau processus en regardant la valeur de retour de <tt>fork</tt>. Pour le nouveau processus, cette valeur vaudra 0, et il devra utiliser la fonction <tt>getpid()</tt> pour obtenir son numéro.

Le processus appelant est appelé le ''père'' alors que le nouveau processus est appelé le ''fils''.

Notez que l'espace mémoire du processus est dupliqué plutôt que partagé. Ceci veut dire que les processus ne peuvent pas communiquer en utilisant leur variables... Par contre, les descripteurs de fichiers du fils sont hérités directement de ceux du père ; ils peuvent donc essayer de communiquer en passant par ces fichiers. (Mais cela pose de nombreux problèmes de synchronisation.)

Voici par exemple un petit programme C qui lance un processus fils:
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {

int pid ;
int pid_fils ;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
} else {
printf(" >> Je suis le fils.\n");
}

return(0);

}
Après compilation, voici un exemple d'exécution du programme résultant :
$ ./pere_fils
> Le processus 8248 démarre...
>> Je suis le fils.
>> Je suis le père (pid du fils = 8249).

Voici un autre exemple d'exécution :
$ ./pere_fils
> Le processus 8269 démarre...
>> Je suis le père (pid du fils = 8270).
>> Je suis le fils.

Notez que les numéros sont différents, et que l'ordre d'affichage n'est pas le même. Cela vient de l'ordonnancement des deux processus qui peut différer.

La technique consistant à faire
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
...
}
montre que malgré le fait que les processus soient identiques à l'origine, on peut faire beaucoup de chose.

:'''Remarque :''' <tt>fork()</tt> n'est pas directement un appel système, mais une fonction qui utilise l'appel système <tt>clone()</tt>. Cet appel système ne fait pas partie de la norme POSIX...

La deuxième technique utilisée dans les systèmes POSIX consiste à utiliser <tt>fork()</tt> pour dupliquer le processus, puis à complètement remplacer le fils par un nouveau processus. La fonction correspondante est la fonction <tt>execv</tt> :
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
execv("/usr/bin/...", argv);
...
}
La fonction <tt>execv</tt> prend 2 arguments : une chaîne contenant le chemin d'accès à un programme, et un tableau d'arguments à donner au programme. (C'est un peu plus compliqué que ça : le premier élément du tableau est le nom du programme, et le tableau doit se terminer par un pointeur NULL.)

Une dernière fonction importante est la fonction <tt>wait(pid)</tt> qui permet à un processus d'attendre l'arrêt du processus <tt>pid</tt>.

-- ...

L'API WIN32 possède de nombreuses fonctions avec des fonctionnalités similaires. Par exemple, la fonction [http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx <tt>CreateProcess</tt>] permet de créer un nouveau processus (comme un <tt>fork</tt> suivi d'un <tt>exec</tt>), mais elle nécessite ... 10 arguments !

----

Un autre moyen de créer des processus est d'utiliser des 'processus légers' appelés Thread. Ces processus légers partage seulement une partie de la mémoire, ce qui en pratique est plus rapide pour simuler un parallélisme. On passe alors par une autre fonction. Sous GNU/Linux, lors de l'écriture d'un programme écrit en C il faut utiliser la bibliothèque pthread.h et lors de la compilation, faire un lien vers celle ci, en utilisant le paramètre -lpthread.

====Arborescence des processus dans les systèmes POSIX====

Nous avons vu que la fonction <tt>fork()</tt> permet de créer un processus fils. Le père connaît le PID de son fils : il lui est donné par la fonction <tt>fork()</tt>. Comme le fils peut lui même créer des processus fils, on obtient rapidement une arborescence de processus.

Vous pouvez visualiser cette arborescence à partir d'un terminal avec la commande <tt>pstree</tt> (l'option <tt>-p</tt> permet de demander l'affichage des PID)
$ pstree -p
init(1)─┬─acpid(25425)
├─atd(14365)
├─console-kit-dae(3632)─┬─{console-kit-dae}(3633)
│ ├─{console-kit-dae}(3641)
...
├─cron(14315)
├─dbus-daemon(15590)
├─dbus-daemon(3511)
...
├─getty(4095)
├─getty(4096)
├─getty(4097)
├─getty(4098)
├─getty(4099)
├─gpm(3528)
...
├─kded4(15769)
├─kdeinit4(15766)───klauncher(15767)
├─kdm(15564)─┬─Xorg(15566)
│ └─kdm(15573)───sh(15608)─┬─conky(15751)
│ ├─fluxbox(15703)───firefox-bin(6063)─┬─{firefox-bin}(6064)
│ │ ├─{firefox-bin}(6065)
...
│ ├─ssh-agent(15698)
│ ├─unclutter(15742)
│ ├─wicd-client(15749)
│ └─xscreensaver(15683)
...
├─rsyslogd(6850)─┬─{rsyslogd}(6140)
│ └─{rsyslogd}(6141)
├─screen(4427)─┬─bash(4428)───pstree(9307)
│ ├─bash(4429)───man(7952)───pager(7965)
│ ├─bash(4430)───vi(30568)
│ ├─bash(18395)───vi(28512)
│ └─mutt(8763)
...

Le processus <tt>init</tt> est l'ancêtre de tout les processus, il a toujours 1 comme PID.

'''Remarque :''' sous Windows, les processus ne sont pas organisé en arborescence...

====Mort d'un processus dans un système POSIX====

Un processus peut se terminer pour plusieurs raisons :
* volontairement, grâce à la fonction <tt>exit()</tt> (POSIX) ou <tt>ExitProcess()</tt> (Windows),
* à cause d'une erreur,
* en recevant un signal d'un autre processus, grâce à la fonction <tt>kill()</tt> (POSIX) ou <tt>TerminateProcess()</tt> (Windows).

Lorsqu'un processus se termine, plusieurs choix sont possibles :
* que fait-on de ses fils ?
* que fait-on de son père ?

Linux fait la chose suivante : quand un processus s'arrête,
* tous ces fils s'arrêtent,
* son père reçoit un signal le prévenant que son fils vient de mourir.

Pour que le père puisse recevoir le signal correspondant, il faut qu'il utilise la fonction <tt>wait()</tt> ou <tt>waitpid()</tt>. Tant que le parent existe et qu'il n'a pas reçu le signal disant qu'un de ces fils est mort, le processus fils n'est pas entièrement supprimé : il devient un ''zombie''. (Il n'occupe plus vraiment de place en mémoire, mais le système garde juste suffisamment d'information pour pouvoir prévenir le père si celui ci demande l'état du fils.)

'''Remarque :''' les processus Windows ne sont pas organisés sous forme d'arborescence. Chaque processus peut surveiller l'état d'un autre processus, s'il connaît son PID. Il n'y a donc pas de notion de processus ''zombie'' sous Windows.

Voici un petit programme C qui crée un processus fils, ne fait rien pendant 20 secondes, puis demande l'état de son fils :
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
int pid ;
int pid_fils ;
int w;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
printf(" >> Je suis le père et j'attends un peu.\n");
sleep(20);
printf(" >> Je suis le père et je demande l'état de mon fils.\n");
wait(&w);
printf(" >> Mon fils est mort (signal %i).\n", w);
while(1) sleep(1);
} else {
printf(" >> Je suis le fils.\n");
while (1) sleep(1);
exit(0);
}
return(0);
}
Si on tue le processus fils pendant que le père ne fait rien, le processus fils devient un zombie. Dès que le père fait le <tt>wait</tt>, il reçoit la valeur du signal qui a terminé le processus et le zombie disparaît.

Si on ne tue pas le processus fils, le père n'exécutera jamais le <tt>printf(" >> Mon fils est mort...);</tt>.

'''Remarque :''' dans un système POSIX, lorsqu'un processus meurt, ses fils deviennent ''orphelins''. Il continuent leur exécution mais sont adopté par <tt>init</tt> (PID : 1). Dans certains cas lorsque le processus est arrêté, il envoie explicitement un signal <tt>SIGTERM</tt> pour tuer ses processus fils. C'est par exemple ce qui arrive lorsqu'on lance des application à partir d'un terminal et que l'on quitte le terminal en question...

===États d'un processus===

On peut imaginer un SE dans lequel les processus pourraient être dans trois états :
* en cours d'exécution,
*bloqué : il attend un événement extérieur pour pouvoir continuer (par exemple une ressource; lorsque la ressource est disponible, il passe à l'état "prêt")
*prêt : suspendu provisoirement pour permettre l'exécution d'un autre processus.

Dans un système avec un unique processeur, au plus un processus peut se trouver dans l'état ''en cours d'exécution''. Par contre, il peut y avoir de nombreux processus dans l'état ''bloqué'' ou dans l'état ''prêt''.

Un processus peut passer d'un état à l'autre :
# de ''en exécution'' à ''bloqué'' lorsqu'une ressource n'est pas disponible (entrées / sortie par exemple),
# de ''bloqué'' à ''prêt'' si la ressource ayant provoqué le blocage devient disponible,
# de ''en exécution'' à ''prêt'' si le système décide de suspendre l'exécution du processus,
# de ''prêt'' à ''en exécution'' si le système décide de lancer l'exécution du processus.

On peut résumer ceci par le graphe de transitions suivant :

[[Image:Diagrammedétatdunprocessus.png]]

Les transition manquantes ne sont pas possible directement mais doivent passer par des transition intermédiaires.

On peut ajouter 2 états :
* ''nouveau'' pour un processus qui vient d'être créé,
* ''terminé'' pour un processus qui vient de se terminé.

Dans les systèmes type ''ordinateur de bureau'', le passage de ''nouveau'' à ''prêt'' est automatique mais dans des systèmes temps réel, un processus peut parfois attendre dans cet état.

L'état ''terminé'' est en général passager. Par exemple, lorsqu'un processus terminé est un zombie, le processus n'est conservé que dans la table des processus. La mémoire utilisé par le processus est libérée. La question de savoir si ceci est véritablement un état du processus est donc essentiellement une question de vocabulaire.

:exercice : ajouter les états ''nouveau'' et ''terminé'' et les transitions correspondantes au graphe précédent. Identifiez des situations provoquant les transitions possibles entre états.

===Ordonnancement des processus===

Nous avons vu qu'il pouvait y avoir de nombreux processus dans la table de processus (environ 150 sur mon ordinateur en ce moment même). Parmi ces processus, un seul (sur une machine à un processeur) peut se trouver dans l'état ''en exécution''. C'est au système d'exploitation de décider qui, à un moment donnée, doit se trouver dans cet état. La partie du système faisant ceci s'appelle ''ordonnanceur'' (ou ''scheduler'' en anglais).
En utilisant le contenu de la table des processus et éventuellement d'autres information, ordonnanceur doit donc gérer les transition entre états de tous les processus, et envoyer l'information nécessaire aux composants adéquat du noyau.

Comme d'habitude, l'ordonnanceur doit faire des compromis entre :
* la vitesse,
* l'utilisation de la mémoire,
* l'optimalité de la solution proposée.

'''Remarque : ''' l'ordonnanceur est lui même un processus (ou un morceau de processus dans le cas des noyaux monolithiques).

====Ordonnancement non préemptif====

'''FIFO.'''
L'algorithme d'ordonnancement le plus facile est probablement celui de type ''FIFO'' : premier arrivé, premier servi. Autrement dit, on préempte premier processus arrivé, et on l'exécute jusqu'à la fin. La seul structure de donnée est donc simplement une ''file''.

'''Plus court temps d'exécution.'''
Dans certain cas, on peut prévoir a l'avance le temps processeur dont aura besoin un processus pour s'exécuter. On peut alors choisir le processus le plus court et l'exécuter en premier. Ceci a en général tendance à diminuer le temps d'attente moyen d'un processus ; mais si des processus courts sont crées régulièrement, on peut assister à une ''famine'' : un processus peut ne jamais s'exécuter.

:exercice : trouver une suite de processus qui provoque une famine.

Ces deux exemples sont acceptables pour un ''traitement par lots'' (batch) par exemple pour des calculs numériques. Ils ne sont par contre pas du tout adaptés pour un ordinateur personnel ou un système temps réels. (Pas de ''multiprogrammation''.)

====Ordonnancement préemptif====

Pour pouvoir donner l'illusion de simultanéité, les processus sont en général exécutés par tranches de temps spécifiées à l'avance (''time slice'' en anglais). Au bout de ce temps, le noyau reçoit une interruption et examine les processus. Il peut décider de continuer le processus courant, ou bien le remplacer par un autre processus. on parle de préemption.

Windows 3.1 ou MacOS 9 étaient des systèmes ''collaboratifs'' car les processus devaient explicitement laisser la main aux autres processus. Tous les systèmes d'exploitation modernes sont maintenant préemptifs. On parle maintenant de système préemptif lorsque la préemption peut s'effectuer même sur des processus en mode noyau.
On parle parfois de noyau préemptible lorsque que les opérations en mode noyau sont elle même préemptibles.

'''Tourniquet.'''
L'algorithme le plus simple est probablement celui du tourniquet (''round Robin'' en anglais). C'est une variante de l'algorithme FIFO vu plus haut, mais qui préempte le processus courant au bout d'un moment. Si ce processus est encore en exécution, on le remet à la fin de la file des processus.

Le temps imparti à chaque processus ne doit pas être trop court (sinon, le changement de contexte prend trop de temps par rapport à l'exécution des processus) ni trop long (sinon, on perd l'illusion de parallélisme, et un processus bloqué risque d'occuper le processeur pendant trop longtemps).

Voici ce qu'on peut trouver dans le livre "Understanding the Linux kernel" :

<cite>
The choice of quantum duration is always a compromise. The rule of thumb adopted by Linux is: choose a duration as long as possible, while keeping good system response time.
</cite>

(extrait du chapitre [http://oreilly.com/catalog/linuxkernel/chapter/ch10.html "Process Scheduling"]).

'''Tourniquet avec priorité.'''
Tous les processus ne naissent pas égaux : certains ont une importance plus élevée (les processus systèmes par exemple). Dans un cas comme le précédent, tous les processus ont le même statut...
Pour corriger ce problème, on utilise parfois un algorithme similaire, mais on choisit le premier processus de priorité la plus élevé possible. Plutôt que de parcourir la file à sa rechercher, on utilise en fait plusieurs files : une pour chaque priorité.

Il faut faire attention car les processus de priorité basse risquent de ne jamais être exécutés (famine)... Par exemple, on peut diminuer petit à petit la priorité des processus qu'on exécute...

Une autre solution pour gérer les priorité en évitant certaines famines est d'exécuter toutes les files, mais pas en proportion égale. Par exemple, on choisit un processus dans les piles de priorité 1, 2, 1, 3, 1, 2, 1, 4, 1, 2, 1, 3, 1, 2, 1, ... De cette manière, les processus de la première file sont exécutés 2 fois plus de fois que ceux de la file 2, et 4 fois plus de fois que ceux de la file 3.

:exercice : donnez un algorithme pour générer la suite précédente pour un nombre donné de files. Il faut que la file ''i'' soit utilisée 2 fois plus souvent que la pile ''i+1''.

'''Répartition garantie.'''
Chaque tache reçoit la même proportion du processeur, et chaque utilisateur reçoit la même proportion également.

'''tirage aléatoire.'''
À chaque étape, on tire un "billet" au hasard, et le processus qui a le "billet gagnant" s'exécute.

Principe de priorité : Les processus qui ont été définit comme prioritaire on plus de "billet" à leur nom et ont donc plus de chance d'être tiré.

''NB : POSIX définit une commande "nice" qui permet e donner à un processus un priorité plus faible (et par conséquent, nice -x augmente cette priorité). Il est évident que tout le monde ne doit pas pouvoir utiliser cette commande, il vaut mieux que l'administrateur se réserve ce droit''

'''Ordonnancement équitable.'''

==La mémoire==

===Introduction===

RAM = Random Acces Memory. C'est ce que l'on appelle couramment la mémoire vive, elle peut être modifié à l'infini et sert à stocker temporairement les fichiers que l'ordinateur exécute.

ROM = Read Only Memory. On l'appelle aussi mémoire fixe ou mémoire morte, dès que l'on enregistre, le contenu d'une mémoire ROM ne peut pas être modifié (ex: un CD-ROM).

'''Gestion de la mémoire : '''

Lors du boot du PC, le système est chargé en mémoire.
Tout processus créé est aussi chargé dans la mémoire.

Lorsque l'on créé uns seul processus, il est plus pratique de le charger en "bas" de la mémoire, à partir de la première case de l'espace mémoire. Puis les nouveaux processus peuvent être charger par dessus. Ainsi la machine comprend où commence l'espace mémoire.

Problèmes :
1 - l'espace d'adressage ne commence pas à 0;
2 - un processus peut demander dynamiquement de la mémoire;
3 - avec un accès direct, un processus peut faire "planter" un autre.

==> Il faut avoir une couche d'abstraction au-dessus de la mémoire physique.

===Espaces d'adressage===

Et si l'on créait des espaces d'adressage distincts pour chaque processus ?
Par exemple : chaque processus utilise des adresse de 0 à n de la mémoire, on converti alors ces adresses en adresses physiques.

Certains des premiers processeurs avaient deux registres supérieurs :

- une Base => adresse physique du début de l'espace d'adressage

- une Limite => adresse physique de fin de l'espace d'adressage

Par exemple, lors de l'exécution d'un processus l'accès à une case "a" se transforme en l'accès à la Base+a et un test pour vérifier que : a+Base < Limite.

Malgré tout, ceci ne résout pas les problèmes liés au fait que des processus sont créés et disparaissent, réclament ou libèrent de la mémoire.

===Va-et-vient (swapping)===

====Idée====

Et si pour gérer tout cela on utilisait une mémoire auxiliaire (disque), pour stocker l'état de la mémoire de processus.

La mémoire vue par les processus ne correspond pas à la mémoire physique. À un instant donné, certains processus peuvent se retrouver sur le disque (dans le SWAP).

Quand un processus apparait, on lui cherche un morceau d'espace libre dans la mémoire.

====gestion de la mémoire====

* tableau de bits
* liste chaînée

====Allocation====

* first fit
* next fit
* best fit
* worst fit

===Mémoire virtuelle===

====Idée====

====Pagination====

====Traduction des adresses====

====Table des pages====

====Table inversée====

====Remplacement des pages====

==Les entrées / sorties==

----
----

==Références==

* le livre « Systèmes d'exploitation » de Andrew Tanenbaum est disponible à la BU
* la page du [http://sos.enix.org/fr/PagePrincipale projet SOS]
* la [http://www.opengroup.org/onlinepubs/009695399/nfindex.html norme POSIX:2004]
* l'[http://msdn.microsoft.com/en-us/library/aa383749(VS.85).aspx API win32]
* [http://www.lemis.com/grog/Documentation/Lions/index.php Commentary on the Sixth Edition UNIX Operating System]

INFO502 : Systèmes d'exploitation

2009-12-07T14:24:23Z

Hatat : /* TP */ Ajout TP3

Ce wiki est un complément de cours pour le cours « info-502 : systèmes d'exploitation ». La participation au wiki est fortement encouragée.

Pour pouvoir modifier les pages, inscrivez-vous (lien en haut à droite) pour obtenir un login et mot de passe. (Choisissez un login du style ''PrenomNom''...)

Je vous conseille d'aller lire [http://meta.wikimedia.org/wiki/Aide:Contenu ce guide] pour vous familiariser avec les wikis.

Exercice : si vous n'en avez pas, créez-vous un compte et essayez de modifier cette page (correction de fautes d'hortographe, rajout de détails, mise en page, ...)

Vous pouvez aussi utiliser la page de discussion pour ... discuter. (Ou poser des questions, faire des commentaires etc.)

----
----
==Auteur du cours==

===Nouvelles===

===Supports===

====TD====

Sujets de TD :
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td1.pdf Ordonnancement],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td2.pdf Gestion de la mémoire],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td3.pdf Systèmes de fichiers].

====TP====

# Découverte de SOS :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp1.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp1.tar.gz code source].
# Gestion de la mémoire du noyau :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp2.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp2.tar.gz code source],
#* Article [http://sos.enix.org/wiki-fr/upload/SOSDownload/sos-texte-art5.pdf Gestion de la mémoire virtuelle du noyau].
# Ordonnancement.

==Introduction==

-- ...

==Repères historiques==

Voici quelques évènements clés dans l'histoire des systèmes d'exploitation. Pour plus de détails, ou pour des compléments sur l'histoire de l'informatique, je vous renvoie sur Wikipedia : [http://en.wikipedia.org/wiki/History_of_operating_systems "History of operating systems"] et [http://en.wikipedia.org/wiki/History_of_computing "History of computing"].

Les premiers ordinateurs ne comportaient pas vraiment de système d'exploitation : c'étaient des opérateurs humains qui géraient tout. (C'était juste après la seconde guerre mondiale, l faut savoir que les langages de programmation n'existaient même pas...) La petite histoire (??) raconte qu'à un moment, les processus pour l'ordinateur de l'université de Cambridge étaient accrochés sur une corde à linge et que c'était la couleur des pinces à linges qui donnait la priorité. (??)

Le passage à la notion de système d'exploitation c'est faite graduellement pour répondre à la complexité de plus en plus grande des ordinateurs et aux demandes des utilisateurs.

Les premier systèmes d'exploitation datent probablement de 1956. Ils permettaient simplement d'exécuter un nouveau programme lorsque le précédent était terminé. Les ordinateurs d'IBM de la famille System/360 ont ensuite eu toute une série de systèmes d'exploitation plus ou moins similaires : OS/360, DOS/360 (rien à voir avec MS-DOS), TSS/360... C'est à cette époque qu'est apparu la notion de multiprogrammation (possibilité d'avoir plusieurs processus entrelacés.)
C'est également au début des années 60 qu'on a commencé à voir des systèmes avec temps partagé : plusieurs utilisateurs pouvaient utiliser un ordinateur. Le système Multics a été, à ce niveau comme à d'autres, assez révolutionnaire. Multics a été utilisé jusqu'en 2000 !

Multics n'était par contre pas approprié pour les mini-ordinateurs où le nombre d'utilisateur est relativement restreint. En 1969, Ken Thomson
a développé une variante simplifié de Multix : Unix...

Ce n'est qu'un peu plus tard (1979) que la première version de DOS (86-DOS ou QDOS) apparaît. 86-DOS sera racheté par Microsoft un 1980...

'''Liens et compléments :'''
* [http://en.wikipedia.org/wiki/Timeline_of_operating_systems Timeline of operating systems]
* généalogie des systèmes Unix : [http://www.levenez.com/unix/ Unix History]
* généalogie de Windows : [http://www.levenez.com/windows/ Windows History]
* généalogie des systèmes non-Unix : [http://www.oshistory.net/metadot/index.pl?id=2165 timeline of non-Unix operating systems]

==Vue d'ensemble==

Ce cours reste assez généraliste et essaie de regarder les principales fonction d'un système d'exploitation. Les systèmes de type Unix (Linux) sera un exemple privilégié. À cause de leur complexité intrinsèque, les évolutions modernes (architectures multicoeur ou multiprocesseur, ...) seront en partie ignorée dans un premier temps.

Les problèmes fins de communication entres processus ne seront que très peu abordés, car ils font l'objet d'un cours séparé (info604) pour la filière info.

Nous allons suivre l'ordre classique consistant à regarder :
# les processus
# la mémoire
# les entrées / sorties

La fin du cours dépendra du temps restant...

===Les processus===

Un processus est simplement un programme « en exécution ». À tout instant, un ordinateur de bureau contemporain contient de nombreux processus qui doivent partager le (les) processeur(s) pour donner l'impression qu'ils s'exécutent « en même temps ». Un des rôles du système d'exploitation consiste à décider dans quel ordre les processus vont effectivement pouvoir utiliser le processus.

===La mémoire===

La mémoire est, comme le processeur, une ressource partagée par les différents processus. Il faut donc gérer la quantité de mémoire allouée et utilisée pour que les processus n'aient pas à s'occuper de ceci. Un des concepts fondamentaux est celui de mémoire virtuelle. Ceci permet d'offrir un espace mémoire pour chacun des processus de manière transparente.

===Les entrées / sorties===

Un ordinateur n'est pas (plus) un système indépendant du reste du monde : il interagit avec l'extérieur à travers des périphériques d'entrées/sorties (clavier / écran / souris / ...). La gestion de ces périphériques pose un ensemble de problèmes que nous aborderons brièvement...

===...===

Une fois ces notions vues, nous regarderons peut-être les problèmes de sécurité, de multimédia ou des architectures multiprocesseurs.

==Préliminaires==

===Quoi ?===

Les ordinateurs, ou plus simplement les micro contrôleurs sont des circuits électroniques avec une puce « processeur ». Le développement d'applications n'est pas facile si on se place au niveau électronique et que l'on parle directement au CPU. Pour faciliter la vie des programmeurs, plusieurs couches d'abstraction sont nécessaires. La première se place au niveau matériel et s'occupe directement des problèmes électroniques ou de très bas niveau. Il s'agit du ''firmware''. Il répond par exemple aux questions comme :
* qu'elle est l'amplitude des signaux envoyés par l'horloge ?
* est-ce que l'UC possède un pipeline ?
* ...
Un firmware est donc forcement très lié au matériel sur lequel il tourne.

La couche suivante est le système d'exploitation à proprement parler. Dans le cas que vous connaissez le mieux (ordinateur personnel), le système d'exploitation fournit une interface pour :
* exécuter un programme
* exécuter plusieurs programmes « en même temps »
* gérer les ressources (temps processeur, mémoire disponible, entrées / sorties)
* les opérations sur les fichiers
* offrir des garanties de sécurité

===Où ?===

On trouve des systèmes d'exploitation partout :

* dans les ordinateurs personnels (Linux, BSD, MacOS, Solaris, Windows, ChromeOS (?))
* dans les PDA (PalmOS, ...)
* dans les téléphones portables (Android, OpenMoko,Symbian,)
* console de jeux
* lecteur MP3 (Rockbox, ...)
* les microcontroleurs « avancés »

===Comment ?===

====Langage de programmation====

Le système d'exploitation se situe entre le firmware (très bas niveau) et l'utilisateur. La nécessité d'accéder à ces ressources de très bas niveau implique que les langages de haut niveaux (Java, Ada, Python, ...) ne sont pas du tout adaptés à l'écriture des systèmes d'exploitation.
Le langage le plus utilisé reste à ce jours le langage C : Linux, BSD, MacOS, Windows, ... sont tous écrits pour leur plus grande partie en C.

Vous avez normalement un cours de C en parallèle, et les TPs utiliseront le langage C. (La référence sur le langage C reste à mon goût le livre de Kernighan et Ritchie : « the C Programming language ». (Disponible en francais à la BU sous le titre « Le langage C : norme Ansi ».) Il existe de nombreux autres livres / documents sur la programmation C comme le [http://www-clips.imag.fr/commun/bernard.cassagne/Introduction_ANSI_C.html polycopié de Bernard Cassagne « introduction au langage C »].

Les premiers systèmes d'exploitation étaient écrits directement en langage machine, ou bien en langage d'assembleur ; et les systèmes actuels comportent encore quelques parties de très bas niveau en langage d'assemblage...

====Notion d'appel système, norme POSIX====

La programmation de haut niveau en C est assez différente de la programmation système. De nombreuses fonctions C utilisent en fait des « appels système », c'est à dire des appels de fonctionnalités propres du système d'exploitation. Les appels système typiques sont :
* les fonctions relatives aux fichiers (création, suppression, modification...)
* les fonctions relatives à la gestion de la mémoire
* les fonctions relatives aux processus (<tt>fork</tt>)
* ...

De nombreux système d'exploitation proposent une interface [http://en.wikipedia.org/wiki/Posix POSIX] (« '''P'''ortable '''O'''perating '''S'''ystem '''I'''nterface for Uni'''x''' »). Cette norme définit entre autres un ensemble de fonctions pour utiliser les appels systèmes.
Le nombre de ces fonctions est relativement faible : une centaine ; et chacune correspond en gros à un appel système. Certaines de ces fonctions ne sont pas définies directement dans le système d'exploitation, mais dans des librairies. Pour Linux, il s'agit en général de la librairie Glibc (GNU C Library).

Par exemple, la fonction <tt>open</tt> (qui permet d'ouvrir un fichier) correspond exactement à un appel système ; alors que la fonction <tt>malloc</tt> (qui permet d'allouer dynamiquement de la mémoire dans le tas) peut générer plusieurs appels système (<tt>brk</tt> et <tt>sbrk</tt>).

Pour visualiser les appels systèmes effectués par un programme sous Linux, vous pouvez utilisez l'utilitaire <tt>strace</tt> ou <tt>ltrace</tt>. Par exemple, dans le shell :
$ strace -e trace=file ls -l 2> trace
permet de récupérer tous les appels systèmes relatifs aux fichiers lors de l'appel à <tt>ls -l</tt>. La liste des appels système est redirigée dans le fichier <tt>trace</tt> qui contiendra par exemple des lignes telles que
lstat64("Desktop", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lgetxattr("Desktop", "security.selinux", 0x8cc08e0, 255) = -1 ENODATA (No data available)
dénotant ainsi un appel aux appels système <tt>lstat64</tt> et <tt>lgetxattr</tt>...

Les principaux systèmes compatibles POSIX sont :
* Linux
* BSD (et variantes)
* Mac OS X
* Solaris

De nombreux appels systèmes sont disponibles directement (sans avoir besoin d'écrire un programme C) à travers le shell. Exécuté dans un terminal, le shell permet, en première approximation, de passer directement des commandes au système d'exploitation. (La norme POSIX définit également un ensemble de fonctions du shell. Il est donc relativement aisé de changer de système d'exploitation tant qu'on reste dans les systèmes compatibles POSIX.)

Windows d'un autre côté utilise l'interface Win32 API, qui définit plusieurs milliers de fonctions. La plupart de ces fonctions peuvent utiliser plusieurs appels système...

Les systèmes d'exploitation qui utilisent l'API Win32 sont :
* Windows, depuis Windows95.

Il est possible d'installer un environnement compatible POSIX sur une machine Windows grâce à Cygwin. (C'est d'ailleurs fortement conseillé si vous ne voulez pas installer une version de Linux ou BSD sur votre ordinateur personnel...)

====Mode noyau / mode utilisateur====

La partie fondamentale du système d'exploitation est le ''noyau'' (''kernel'' en anglais). C'est la couche de plus bas niveau.

Les fonctionnalités de très bas niveau offertes par le noyau peuvent facilement planter l'ordinateur. Il faut donc une politique de restriction pour que tous les programmes ne puissent y accéder dans leur totalité. On parle de
* mode noyau
* mode utilisateur

Dans le mode utilisateur, on ne peut accéder à ces fonctionnalités qu'a travers les appels systèmes ; dans le mode noyau, on peut tout faire... Bien entendu, un appel système doit passer momentanément en mode noyau pour pouvoir exécuter les commandes pertinentes, puis il repasse automatiquement en mode utilisateur.

La définition d'un appel système pourrait donc être « fonctionnalité atomique nécessitant un passage en mode noyau ».

====Noyau, noyau monolithique, micro-noyau====

La partie principale du système d'exploitation. C'est lui qui gère les ressources, les entrées / sorties, la communication entre processus, ... Les deux architectures principales pour un noyau sont :
* noyau monolithique
* micro-noyau
La plupart des systèmes actuels sont basés sur un noyau monolithique (Linux, BSD, Mac OS X, Solaris, Windows).

Les noyaux monolithiques sont parfois décrits comme « sans vraie structure » : une grosse soupe où cohabitent toutes les fonctionnalités du système d'exploitation. L'idée d'avoir un système unique qui gère tout est effectivement peu attirante et peut poser quelques problèmes de génie logiciel...
Un noyau monolithique est donc la couche entre le matériel et les programmes utilisateurs. Pour éviter de compiler des noyaux énormes, les noyaux monolithiques actuels utilisent en plus la notion de ''module''. Ce sont des morceaux du noyau qu'on peut charger ou décharger au besoin. Si l'interface est connue, ces modules peuvent éventuellement être en binaire, ce qui permet d'utiliser des modules propriétaires avec un noyau libre.
Sous Linux, la commande
$ lsmod
permet d'obtenir la liste des modules chargés dans le noyau.

Les micro-noyaux d'un autre coté sont basés sur la remarque que seule une toute petite partie du noyau accède effectivement au matériel. Seule cette petite partie nécessite donc des privilèges et effectue des appels système. Le reste du système d'exploitation peut être programmé en mode utilisateur, « au dessus » de cette partie. Par exemple, le micro noyau offrira la possibilité de charger un nouveau processus, mais l'ordonnanceur (qui choisit quel processus devra être chargé) ne fera pas partie du micro-noyau. On parle parfois de ''services'' / ''serveurs'' au dessus du micro-noyau.
Ceci permet d'avoir un noyau bas niveau beaucoup plus petit. Bien que ceci soit une bonne idée, et que les micro-noyaux puissent fournir de meilleurs garanties de sécurité, peu de noyaux sont effectivement des micro-noyaux. Un des problèmes est qu'un tel micro-noyau est un peu plus lent que ses cousins monolithiques. La raison principale est que dans le cas d'un micro-noyau, un appel système nécessite en fait des communications inter-processus.
Andrew Tanenbaum est un fervent défenseur des micro-noyaux.

Une autre architecture possible est d'utiliser des couches successives, chacune avec des privilèges réduits. Le système Multics avait cette architecture.
Par exemple, dans le système THE (1965), les couches étaient les suivantes :
# noyau bas niveau, multiprogrammation
# allocation de la mémoire pour les processus
# IPC (communication inter processus)
# entrées / sorties (buffer, etc.)
# programmes utilisateurs (compilation, exécution, ...)
# utilisateur (Dijkstra a annoté la description de cette couche par ''« not implemented by us »'')

Une dernière catégorie de noyau est la catégorie des machines virtuelles. Ces noyaux sont un peu à part, car il s'agit d'émuler un système d'exploitation ou du matériel particulier à l'intérieur d'un autre système d'exploitation ou matériel. Le mode noyau de la machine virtuelle est en fait dans le mode utilisateur du noyau original...

==Les processus==

===Introduction===

Allez hop commençons par une petite définition du type wikipédia :

Un processus (en anglais, process), en informatique, est défini par :
* un ensemble d'instructions à exécuter (un programme) ;
* un espace mémoire pour les données de travail ;
* éventuellement, d'autres ressources, comme des descripteurs de fichiers, des ports réseau, etc.

Un ordinateur équipé d'un système d'exploitation à temps partagé est capable d'exécuter plusieurs processus de façon « quasi- simultanée ». Par analogie avec les télécommunications, on nomme multiplexage (A. Tanenbaum parle de ''multiprogrammation'') ce procédé. S'il y a plusieurs processeurs, le système essaie de répartir les processus de manière équitable sur les processeurs disponibles.

Le processus doit être imaginé comme quelque chose qui prend du temps, donc qui a un début et (parfois) une fin. De nombreux processus ne se terminent normalement jamais : système d'exploitation, serveurs web, serveurs mail, ... D'autres processus plus légers qui ne se terminent pas sont les ''daemon'' (acronyme ''a posteriori'' de "disk and execution monitor") du monde Unix.

Certains processus sont démarrés très tôt lors de la séquence de boot. Le système d'exploitation est un tel processus. Sinon, les processus sont normalement démarrés grâce à un appel système à partir d'un autre processus. L'utilisateur peut par exemple demander explicitement un nouveau processus (sous POSIX, grâce à un <tt>fork</tt> puis <tt>exec</tt>) ; mais la plupart du temps, il le fera à travers une application, par exemple en double-cliquant sur l'icône d'un programme dans l'explorateur de fichiers.

Le système d'exploitation est chargé d'allouer les ressources (mémoires, temps processeur, entrées/sorties) nécessaires aux processus et d'assurer que le fonctionnement d'un processus n'interfère pas avec celui des autres (isolation).

Pas sûr d'avoir tout compris ? Ce n'est pas grave, essayons autrement.
:'''Définition :''' un processus est un programme en train de s'exécuter.
Cette définition implique en particulier que un programme (navigateur Firefox par exemple) peut correspondre à
* zéro processus si on ne l'a pas lancé,
* un processus si on l'a lancé,
* plusieurs processus si on l'a lancé plusieurs fois.
(''Remarque :'' pour un programme comme Firefox, il y a fort à parier que l'exécution d'une seule instance de Firefox génère de multiples sous-processus...)

Que se passe-t-il quand je démarre une application?

:L'ordinateur à une nouvelle tâche à accomplir, les instructions correspondantes sont donc envoyées au processeur. Comme il a plusieurs choses à faire le choix des instructions à exécuter n'est pas forcement simple. Il faut faire en sorte de partager le processeur entre les différentes tâches de manière équitable : c'est la fameuse gestion des processus.
:Ceci permet de réaliser plusieurs activités en ~même temps~. Grâce à la gestion des processus on peut regarder un film (obtenu par des moyens tout à fait légaux cela va de soit), tout en jouant à la dame de pique.
:(et dire que certain(e)s affirment que l'homme est mono tâche)

Plusieurs processus indépendants peuvent être ''actifs'' en même temps, mais sauf si l'ordinateur possède suffisamment de processeurs, on ne peut pas les exécuter simultanément. L'impression que plusieurs programmes s'exécutent ''en même temps'' vient simplement du fait que le processeur alterne rapidement entre eux.
Comme le temps d'exécution d'une instruction par le processeur est très court, de l'ordre de la nano-seconde, le processeur peut réaliser plusieurs centaines de millions d'instructions par seconde. Ainsi, une tranche de temps de quelques fractions de seconde, partagée entre plusieurs processus, donne à l'échelle macroscopique l'illusion de la simultanéité.

'''En résumé :''' un système d'exploitation doit la plupart du temps traiter plusieurs tâches en même temps, et comme il n'a, en général, qu'un seul processeur, il devra contourner ce problème grâce à un pseudo-parallélisme. Il traite une tâche à la fois, s'interrompt et passe à la suivante. La commutation de tâches étant très rapide, il donne l'illusion d'effectuer un traitement simultané.

===La table des processus===

L'information sur les processus est conservé par le système dans une structure de données appelée ''table des processus''. Cette table contient toutes les informations nécessaires à la gestion des processus :
* état du processus
* PID
* droits
* répertoire de travail
* pointeur vers la pile
* priorités
* ...

Sous Linux, on peut accéder à ces informations à travers le système de fichiers virtuel "Procfs". Il suffit d'aller dans le répertoire <tt>/proc/</tt>.

===Création d'un processus===

Pour les système POSIX, la création d'un processus est très simple : on utilise la fonction <tt>fork()</tt>. En C, le prototype de la fonction se trouve dans le fichier d'entêtes <tt>unistd.h</tt>.

Cette fonction prend 0 argument et permet de faire la chose suivante : elle crée un nouveau processus qui est une copie conforme du processus appelant. La seule différence visible entre l'ancien et le nouveau processus est que les processus ont un numéro (PID) différent. Pour le processus appelant, il peut obtenir le PID du nouveau processus en regardant la valeur de retour de <tt>fork</tt>. Pour le nouveau processus, cette valeur vaudra 0, et il devra utiliser la fonction <tt>getpid()</tt> pour obtenir son numéro.

Le processus appelant est appelé le ''père'' alors que le nouveau processus est appelé le ''fils''.

Notez que l'espace mémoire du processus est dupliqué plutôt que partagé. Ceci veut dire que les processus ne peuvent pas communiquer en utilisant leur variables... Par contre, les descripteurs de fichiers du fils sont hérités directement de ceux du père ; ils peuvent donc essayer de communiquer en passant par ces fichiers. (Mais cela pose de nombreux problèmes de synchronisation.)

Voici par exemple un petit programme C qui lance un processus fils:
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {

int pid ;
int pid_fils ;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
} else {
printf(" >> Je suis le fils.\n");
}

return(0);

}
Après compilation, voici un exemple d'exécution du programme résultant :
$ ./pere_fils
> Le processus 8248 démarre...
>> Je suis le fils.
>> Je suis le père (pid du fils = 8249).

Voici un autre exemple d'exécution :
$ ./pere_fils
> Le processus 8269 démarre...
>> Je suis le père (pid du fils = 8270).
>> Je suis le fils.

Notez que les numéros sont différents, et que l'ordre d'affichage n'est pas le même. Cela vient de l'ordonnancement des deux processus qui peut différer.

La technique consistant à faire
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
...
}
montre que malgré le fait que les processus soient identiques à l'origine, on peut faire beaucoup de chose.

:'''Remarque :''' <tt>fork()</tt> n'est pas directement un appel système, mais une fonction qui utilise l'appel système <tt>clone()</tt>. Cet appel système ne fait pas partie de la norme POSIX...

La deuxième technique utilisée dans les systèmes POSIX consiste à utiliser <tt>fork()</tt> pour dupliquer le processus, puis à complètement remplacer le fils par un nouveau processus. La fonction correspondante est la fonction <tt>execv</tt> :
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
execv("/usr/bin/...", argv);
...
}
La fonction <tt>execv</tt> prend 2 arguments : une chaîne contenant le chemin d'accès à un programme, et un tableau d'arguments à donner au programme. (C'est un peu plus compliqué que ça : le premier élément du tableau est le nom du programme, et le tableau doit se terminer par un pointeur NULL.)

Une dernière fonction importante est la fonction <tt>wait(pid)</tt> qui permet à un processus d'attendre l'arrêt du processus <tt>pid</tt>.

-- ...

L'API WIN32 possède de nombreuses fonctions avec des fonctionnalités similaires. Par exemple, la fonction [http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx <tt>CreateProcess</tt>] permet de créer un nouveau processus (comme un <tt>fork</tt> suivi d'un <tt>exec</tt>), mais elle nécessite ... 10 arguments !

----

Un autre moyen de créer des processus est d'utiliser des 'processus légers' appelés Thread. Ces processus légers partage seulement une partie de la mémoire, ce qui en pratique est plus rapide pour simuler un parallélisme. On passe alors par une autre fonction. Sous GNU/Linux, lors de l'écriture d'un programme écrit en C il faut utiliser la bibliothèque pthread.h et lors de la compilation, faire un lien vers celle ci, en utilisant le paramètre -lpthread.

====Arborescence des processus dans les systèmes POSIX====

Nous avons vu que la fonction <tt>fork()</tt> permet de créer un processus fils. Le père connaît le PID de son fils : il lui est donné par la fonction <tt>fork()</tt>. Comme le fils peut lui même créer des processus fils, on obtient rapidement une arborescence de processus.

Vous pouvez visualiser cette arborescence à partir d'un terminal avec la commande <tt>pstree</tt> (l'option <tt>-p</tt> permet de demander l'affichage des PID)
$ pstree -p
init(1)─┬─acpid(25425)
├─atd(14365)
├─console-kit-dae(3632)─┬─{console-kit-dae}(3633)
│ ├─{console-kit-dae}(3641)
...
├─cron(14315)
├─dbus-daemon(15590)
├─dbus-daemon(3511)
...
├─getty(4095)
├─getty(4096)
├─getty(4097)
├─getty(4098)
├─getty(4099)
├─gpm(3528)
...
├─kded4(15769)
├─kdeinit4(15766)───klauncher(15767)
├─kdm(15564)─┬─Xorg(15566)
│ └─kdm(15573)───sh(15608)─┬─conky(15751)
│ ├─fluxbox(15703)───firefox-bin(6063)─┬─{firefox-bin}(6064)
│ │ ├─{firefox-bin}(6065)
...
│ ├─ssh-agent(15698)
│ ├─unclutter(15742)
│ ├─wicd-client(15749)
│ └─xscreensaver(15683)
...
├─rsyslogd(6850)─┬─{rsyslogd}(6140)
│ └─{rsyslogd}(6141)
├─screen(4427)─┬─bash(4428)───pstree(9307)
│ ├─bash(4429)───man(7952)───pager(7965)
│ ├─bash(4430)───vi(30568)
│ ├─bash(18395)───vi(28512)
│ └─mutt(8763)
...

Le processus <tt>init</tt> est l'ancêtre de tout les processus, il a toujours 1 comme PID.

'''Remarque :''' sous Windows, les processus ne sont pas organisé en arborescence...

====Mort d'un processus dans un système POSIX====

Un processus peut se terminer pour plusieurs raisons :
* volontairement, grâce à la fonction <tt>exit()</tt> (POSIX) ou <tt>ExitProcess()</tt> (Windows),
* à cause d'une erreur,
* en recevant un signal d'un autre processus, grâce à la fonction <tt>kill()</tt> (POSIX) ou <tt>TerminateProcess()</tt> (Windows).

Lorsqu'un processus se termine, plusieurs choix sont possibles :
* que fait-on de ses fils ?
* que fait-on de son père ?

Linux fait la chose suivante : quand un processus s'arrête,
* tous ces fils s'arrêtent,
* son père reçoit un signal le prévenant que son fils vient de mourir.

Pour que le père puisse recevoir le signal correspondant, il faut qu'il utilise la fonction <tt>wait()</tt> ou <tt>waitpid()</tt>. Tant que le parent existe et qu'il n'a pas reçu le signal disant qu'un de ces fils est mort, le processus fils n'est pas entièrement supprimé : il devient un ''zombie''. (Il n'occupe plus vraiment de place en mémoire, mais le système garde juste suffisamment d'information pour pouvoir prévenir le père si celui ci demande l'état du fils.)

'''Remarque :''' les processus Windows ne sont pas organisés sous forme d'arborescence. Chaque processus peut surveiller l'état d'un autre processus, s'il connaît son PID. Il n'y a donc pas de notion de processus ''zombie'' sous Windows.

Voici un petit programme C qui crée un processus fils, ne fait rien pendant 20 secondes, puis demande l'état de son fils :
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
int pid ;
int pid_fils ;
int w;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
printf(" >> Je suis le père et j'attends un peu.\n");
sleep(20);
printf(" >> Je suis le père et je demande l'état de mon fils.\n");
wait(&w);
printf(" >> Mon fils est mort (signal %i).\n", w);
while(1) sleep(1);
} else {
printf(" >> Je suis le fils.\n");
while (1) sleep(1);
exit(0);
}
return(0);
}
Si on tue le processus fils pendant que le père ne fait rien, le processus fils devient un zombie. Dès que le père fait le <tt>wait</tt>, il reçoit la valeur du signal qui a terminé le processus et le zombie disparaît.

Si on ne tue pas le processus fils, le père n'exécutera jamais le <tt>printf(" >> Mon fils est mort...);</tt>.

'''Remarque :''' dans un système POSIX, lorsqu'un processus meurt, ses fils deviennent ''orphelins''. Il continuent leur exécution mais sont adopté par <tt>init</tt> (PID : 1). Dans certains cas lorsque le processus est arrêté, il envoie explicitement un signal <tt>SIGTERM</tt> pour tuer ses processus fils. C'est par exemple ce qui arrive lorsqu'on lance des application à partir d'un terminal et que l'on quitte le terminal en question...

===États d'un processus===

On peut imaginer un SE dans lequel les processus pourraient être dans trois états :
* en cours d'exécution,
*bloqué : il attend un événement extérieur pour pouvoir continuer (par exemple une ressource; lorsque la ressource est disponible, il passe à l'état "prêt")
*prêt : suspendu provisoirement pour permettre l'exécution d'un autre processus.

Dans un système avec un unique processeur, au plus un processus peut se trouver dans l'état ''en cours d'exécution''. Par contre, il peut y avoir de nombreux processus dans l'état ''bloqué'' ou dans l'état ''prêt''.

Un processus peut passer d'un état à l'autre :
# de ''en exécution'' à ''bloqué'' lorsqu'une ressource n'est pas disponible (entrées / sortie par exemple),
# de ''bloqué'' à ''prêt'' si la ressource ayant provoqué le blocage devient disponible,
# de ''en exécution'' à ''prêt'' si le système décide de suspendre l'exécution du processus,
# de ''prêt'' à ''en exécution'' si le système décide de lancer l'exécution du processus.

On peut résumer ceci par le graphe de transitions suivant :

[[Image:Diagrammedétatdunprocessus.png]]

Les transition manquantes ne sont pas possible directement mais doivent passer par des transition intermédiaires.

On peut ajouter 2 états :
* ''nouveau'' pour un processus qui vient d'être créé,
* ''terminé'' pour un processus qui vient de se terminé.

Dans les systèmes type ''ordinateur de bureau'', le passage de ''nouveau'' à ''prêt'' est automatique mais dans des systèmes temps réel, un processus peut parfois attendre dans cet état.

L'état ''terminé'' est en général passager. Par exemple, lorsqu'un processus terminé est un zombie, le processus n'est conservé que dans la table des processus. La mémoire utilisé par le processus est libérée. La question de savoir si ceci est véritablement un état du processus est donc essentiellement une question de vocabulaire.

:exercice : ajouter les états ''nouveau'' et ''terminé'' et les transitions correspondantes au graphe précédent. Identifiez des situations provoquant les transitions possibles entre états.

===Ordonnancement des processus===

Nous avons vu qu'il pouvait y avoir de nombreux processus dans la table de processus (environ 150 sur mon ordinateur en ce moment même). Parmi ces processus, un seul (sur une machine à un processeur) peut se trouver dans l'état ''en exécution''. C'est au système d'exploitation de décider qui, à un moment donnée, doit se trouver dans cet état. La partie du système faisant ceci s'appelle ''ordonnanceur'' (ou ''scheduler'' en anglais).
En utilisant le contenu de la table des processus et éventuellement d'autres information, ordonnanceur doit donc gérer les transition entre états de tous les processus, et envoyer l'information nécessaire aux composants adéquat du noyau.

Comme d'habitude, l'ordonnanceur doit faire des compromis entre :
* la vitesse,
* l'utilisation de la mémoire,
* l'optimalité de la solution proposée.

'''Remarque : ''' l'ordonnanceur est lui même un processus (ou un morceau de processus dans le cas des noyaux monolithiques).

====Ordonnancement non préemptif====

'''FIFO.'''
L'algorithme d'ordonnancement le plus facile est probablement celui de type ''FIFO'' : premier arrivé, premier servi. Autrement dit, on préempte premier processus arrivé, et on l'exécute jusqu'à la fin. La seul structure de donnée est donc simplement une ''file''.

'''Plus court temps d'exécution.'''
Dans certain cas, on peut prévoir a l'avance le temps processeur dont aura besoin un processus pour s'exécuter. On peut alors choisir le processus le plus court et l'exécuter en premier. Ceci a en général tendance à diminuer le temps d'attente moyen d'un processus ; mais si des processus courts sont crées régulièrement, on peut assister à une ''famine'' : un processus peut ne jamais s'exécuter.

:exercice : trouver une suite de processus qui provoque une famine.

Ces deux exemples sont acceptables pour un ''traitement par lots'' (batch) par exemple pour des calculs numériques. Ils ne sont par contre pas du tout adaptés pour un ordinateur personnel ou un système temps réels. (Pas de ''multiprogrammation''.)

====Ordonnancement préemptif====

Pour pouvoir donner l'illusion de simultanéité, les processus sont en général exécutés par tranches de temps spécifiées à l'avance (''time slice'' en anglais). Au bout de ce temps, le noyau reçoit une interruption et examine les processus. Il peut décider de continuer le processus courant, ou bien le remplacer par un autre processus. on parle de préemption.

Windows 3.1 ou MacOS 9 étaient des systèmes ''collaboratifs'' car les processus devaient explicitement laisser la main aux autres processus. Tous les systèmes d'exploitation modernes sont maintenant préemptifs. On parle maintenant de système préemptif lorsque la préemption peut s'effectuer même sur des processus en mode noyau.
On parle parfois de noyau préemptible lorsque que les opérations en mode noyau sont elle même préemptibles.

'''Tourniquet.'''
L'algorithme le plus simple est probablement celui du tourniquet (''round Robin'' en anglais). C'est une variante de l'algorithme FIFO vu plus haut, mais qui préempte le processus courant au bout d'un moment. Si ce processus est encore en exécution, on le remet à la fin de la file des processus.

Le temps imparti à chaque processus ne doit pas être trop court (sinon, le changement de contexte prend trop de temps par rapport à l'exécution des processus) ni trop long (sinon, on perd l'illusion de parallélisme, et un processus bloqué risque d'occuper le processeur pendant trop longtemps).

Voici ce qu'on peut trouver dans le livre "Understanding the Linux kernel" :

<cite>
The choice of quantum duration is always a compromise. The rule of thumb adopted by Linux is: choose a duration as long as possible, while keeping good system response time.
</cite>

(extrait du chapitre [http://oreilly.com/catalog/linuxkernel/chapter/ch10.html "Process Scheduling"]).

'''Tourniquet avec priorité.'''
Tous les processus ne naissent pas égaux : certains ont une importance plus élevée (les processus systèmes par exemple). Dans un cas comme le précédent, tous les processus ont le même statut...
Pour corriger ce problème, on utilise parfois un algorithme similaire, mais on choisit le premier processus de priorité la plus élevé possible. Plutôt que de parcourir la file à sa rechercher, on utilise en fait plusieurs files : une pour chaque priorité.

Il faut faire attention car les processus de priorité basse risquent de ne jamais être exécutés (famine)... Par exemple, on peut diminuer petit à petit la priorité des processus qu'on exécute...

Une autre solution pour gérer les priorité en évitant certaines famines est d'exécuter toutes les files, mais pas en proportion égale. Par exemple, on choisit un processus dans les piles de priorité 1, 2, 1, 3, 1, 2, 1, 4, 1, 2, 1, 3, 1, 2, 1, ... De cette manière, les processus de la première file sont exécutés 2 fois plus de fois que ceux de la file 2, et 4 fois plus de fois que ceux de la file 3.

:exercice : donnez un algorithme pour générer la suite précédente pour un nombre donné de files. Il faut que la file ''i'' soit utilisée 2 fois plus souvent que la pile ''i+1''.

'''Répartition garantie.'''
Chaque tache reçoit la même proportion du processeur, et chaque utilisateur reçoit la même proportion également.

'''tirage aléatoire.'''
À chaque étape, on tire un "billet" au hasard, et le processus qui a le "billet gagnant" s'exécute.

Principe de priorité : Les processus qui ont été définit comme prioritaire on plus de "billet" à leur nom et ont donc plus de chance d'être tiré.

''NB : POSIX définit une commande "nice" qui permet e donner à un processus un priorité plus faible (et par conséquent, nice -x augmente cette priorité). Il est évident que tout le monde ne doit pas pouvoir utiliser cette commande, il vaut mieux que l'administrateur se réserve ce droit''

'''Ordonnancement équitable.'''

==La mémoire==

===Introduction===

RAM = Random Acces Memory. C'est ce que l'on appelle couramment la mémoire vive, elle peut être modifié à l'infini et sert à stocker temporairement les fichiers que l'ordinateur exécute.

ROM = Read Only Memory. On l'appelle aussi mémoire fixe ou mémoire morte, dès que l'on enregistre, le contenu d'une mémoire ROM ne peut pas être modifié (ex: un CD-ROM).

'''Gestion de la mémoire : '''

Lors du boot du PC, le système est chargé en mémoire.
Tout processus créé est aussi chargé dans la mémoire.

Lorsque l'on créé uns seul processus, il est plus pratique de le charger en "bas" de la mémoire, à partir de la première case de l'espace mémoire. Puis les nouveaux processus peuvent être charger par dessus. Ainsi la machine comprend où commence l'espace mémoire.

Problèmes :
1 - l'espace d'adressage ne commence pas à 0;
2 - un processus peut demander dynamiquement de la mémoire;
3 - avec un accès direct, un processus peut faire "planter" un autre.

==> Il faut avoir une couche d'abstraction au-dessus de la mémoire physique.

===Espaces d'adressage===

Et si l'on créait des espaces d'adressage distincts pour chaque processus ?
Par exemple : chaque processus utilise des adresse de 0 à n de la mémoire, on converti alors ces adresses en adresses physiques.

Certains des premiers processeurs avaient deux registres supérieurs :

- une Base => adresse physique du début de l'espace d'adressage

- une Limite => adresse physique de fin de l'espace d'adressage

Par exemple, lors de l'exécution d'un processus l'accès à une case "a" se transforme en l'accès à la Base+a et un test pour vérifier que : a+Base < Limite.

Malgré tout, ceci ne résout pas les problèmes liés au fait que des processus sont créés et disparaissent, réclament ou libèrent de la mémoire.

===Va-et-vient (swapping)===

====Idée====

Et si pour gérer tout cela on utilisait une mémoire auxiliaire (disque), pour stocker l'état de la mémoire de processus.

La mémoire vue par les processus ne correspond pas à la mémoire physique. À un instant donné, certains processus peuvent se retrouver sur le disque (dans le SWAP).

Quand un processus apparait, on lui cherche un morceau d'espace libre dans la mémoire.

====gestion de la mémoire====

* tableau de bits
* liste chaînée

====Allocation====

* first fit
* next fit
* best fit
* worst fit

===Mémoire virtuelle===

====Idée====

====Pagination====

====Traduction des adresses====

====Table des pages====

====Table inversée====

====Remplacement des pages====

==Les entrées / sorties==

----
----

==Références==

* le livre « Systèmes d'exploitation » de Andrew Tanenbaum est disponible à la BU
* la page du [http://sos.enix.org/fr/PagePrincipale projet SOS]
* la [http://www.opengroup.org/onlinepubs/009695399/nfindex.html norme POSIX:2004]
* l'[http://msdn.microsoft.com/en-us/library/aa383749(VS.85).aspx API win32]
* [http://www.lemis.com/grog/Documentation/Lions/index.php Commentary on the Sixth Edition UNIX Operating System]

INFO502 : Systèmes d'exploitation

2009-12-04T12:54:15Z

Hatat : /* TP */ Typo

Ce wiki est un complément de cours pour le cours « info-502 : systèmes d'exploitation ». La participation au wiki est fortement encouragée.

Pour pouvoir modifier les pages, inscrivez-vous (lien en haut à droite) pour obtenir un login et mot de passe. (Choisissez un login du style ''PrenomNom''...)

Je vous conseille d'aller lire [http://meta.wikimedia.org/wiki/Aide:Contenu ce guide] pour vous familiariser avec les wikis.

Exercice : si vous n'en avez pas, créez-vous un compte et essayez de modifier cette page (correction de fautes d'hortographe, rajout de détails, mise en page, ...)

Vous pouvez aussi utiliser la page de discussion pour ... discuter. (Ou poser des questions, faire des commentaires etc.)

----
----
==Auteur du cours==

===Nouvelles===

===Supports===

====TD====

Sujets de TD :
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td1.pdf Ordonnancement],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td2.pdf Gestion de la mémoire],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td3.pdf Systèmes de fichiers].

====TP====

# Découverte de SOS :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp1.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp1.tar.gz code source].
# Gestion de la mémoire du noyau :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp2.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp2.tar.gz code source],
#* Article [http://sos.enix.org/wiki-fr/upload/SOSDownload/sos-texte-art5.pdf Gestion de la mémoire virtuelle du noyau].

==Introduction==

-- ...

==Repères historiques==

Voici quelques évènements clés dans l'histoire des systèmes d'exploitation. Pour plus de détails, ou pour des compléments sur l'histoire de l'informatique, je vous renvoie sur Wikipedia : [http://en.wikipedia.org/wiki/History_of_operating_systems "History of operating systems"] et [http://en.wikipedia.org/wiki/History_of_computing "History of computing"].

Les premiers ordinateurs ne comportaient pas vraiment de système d'exploitation : c'étaient des opérateurs humains qui géraient tout. (C'était juste après la seconde guerre mondiale, l faut savoir que les langages de programmation n'existaient même pas...) La petite histoire (??) raconte qu'à un moment, les processus pour l'ordinateur de l'université de Cambridge étaient accrochés sur une corde à linge et que c'était la couleur des pinces à linges qui donnait la priorité. (??)

Le passage à la notion de système d'exploitation c'est faite graduellement pour répondre à la complexité de plus en plus grande des ordinateurs et aux demandes des utilisateurs.

Les premier systèmes d'exploitation datent probablement de 1956. Ils permettaient simplement d'exécuter un nouveau programme lorsque le précédent était terminé. Les ordinateurs d'IBM de la famille System/360 ont ensuite eu toute une série de systèmes d'exploitation plus ou moins similaires : OS/360, DOS/360 (rien à voir avec MS-DOS), TSS/360... C'est à cette époque qu'est apparu la notion de multiprogrammation (possibilité d'avoir plusieurs processus entrelacés.)
C'est également au début des années 60 qu'on a commencé à voir des systèmes avec temps partagé : plusieurs utilisateurs pouvaient utiliser un ordinateur. Le système Multics a été, à ce niveau comme à d'autres, assez révolutionnaire. Multics a été utilisé jusqu'en 2000 !

Multics n'était par contre pas approprié pour les mini-ordinateurs où le nombre d'utilisateur est relativement restreint. En 1969, Ken Thomson
a développé une variante simplifié de Multix : Unix...

Ce n'est qu'un peu plus tard (1979) que la première version de DOS (86-DOS ou QDOS) apparaît. 86-DOS sera racheté par Microsoft un 1980...

'''Liens et compléments :'''
* [http://en.wikipedia.org/wiki/Timeline_of_operating_systems Timeline of operating systems]
* généalogie des systèmes Unix : [http://www.levenez.com/unix/ Unix History]
* généalogie de Windows : [http://www.levenez.com/windows/ Windows History]
* généalogie des systèmes non-Unix : [http://www.oshistory.net/metadot/index.pl?id=2165 timeline of non-Unix operating systems]

==Vue d'ensemble==

Ce cours reste assez généraliste et essaie de regarder les principales fonction d'un système d'exploitation. Les systèmes de type Unix (Linux) sera un exemple privilégié. À cause de leur complexité intrinsèque, les évolutions modernes (architectures multicoeur ou multiprocesseur, ...) seront en partie ignorée dans un premier temps.

Les problèmes fins de communication entres processus ne seront que très peu abordés, car ils font l'objet d'un cours séparé (info604) pour la filière info.

Nous allons suivre l'ordre classique consistant à regarder :
# les processus
# la mémoire
# les entrées / sorties

La fin du cours dépendra du temps restant...

===Les processus===

Un processus est simplement un programme « en exécution ». À tout instant, un ordinateur de bureau contemporain contient de nombreux processus qui doivent partager le (les) processeur(s) pour donner l'impression qu'ils s'exécutent « en même temps ». Un des rôles du système d'exploitation consiste à décider dans quel ordre les processus vont effectivement pouvoir utiliser le processus.

===La mémoire===

La mémoire est, comme le processeur, une ressource partagée par les différents processus. Il faut donc gérer la quantité de mémoire allouée et utilisée pour que les processus n'aient pas à s'occuper de ceci. Un des concepts fondamentaux est celui de mémoire virtuelle. Ceci permet d'offrir un espace mémoire pour chacun des processus de manière transparente.

===Les entrées / sorties===

Un ordinateur n'est pas (plus) un système indépendant du reste du monde : il interagit avec l'extérieur à travers des périphériques d'entrées/sorties (clavier / écran / souris / ...). La gestion de ces périphériques pose un ensemble de problèmes que nous aborderons brièvement...

===...===

Une fois ces notions vues, nous regarderons peut-être les problèmes de sécurité, de multimédia ou des architectures multiprocesseurs.

==Préliminaires==

===Quoi ?===

Les ordinateurs, ou plus simplement les micro contrôleurs sont des circuits électroniques avec une puce « processeur ». Le développement d'applications n'est pas facile si on se place au niveau électronique et que l'on parle directement au CPU. Pour faciliter la vie des programmeurs, plusieurs couches d'abstraction sont nécessaires. La première se place au niveau matériel et s'occupe directement des problèmes électroniques ou de très bas niveau. Il s'agit du ''firmware''. Il répond par exemple aux questions comme :
* qu'elle est l'amplitude des signaux envoyés par l'horloge ?
* est-ce que l'UC possède un pipeline ?
* ...
Un firmware est donc forcement très lié au matériel sur lequel il tourne.

La couche suivante est le système d'exploitation à proprement parler. Dans le cas que vous connaissez le mieux (ordinateur personnel), le système d'exploitation fournit une interface pour :
* exécuter un programme
* exécuter plusieurs programmes « en même temps »
* gérer les ressources (temps processeur, mémoire disponible, entrées / sorties)
* les opérations sur les fichiers
* offrir des garanties de sécurité

===Où ?===

On trouve des systèmes d'exploitation partout :

* dans les ordinateurs personnels (Linux, BSD, MacOS, Solaris, Windows, ChromeOS (?))
* dans les PDA (PalmOS, ...)
* dans les téléphones portables (Android, OpenMoko,Symbian,)
* console de jeux
* lecteur MP3 (Rockbox, ...)
* les microcontroleurs « avancés »

===Comment ?===

====Langage de programmation====

Le système d'exploitation se situe entre le firmware (très bas niveau) et l'utilisateur. La nécessité d'accéder à ces ressources de très bas niveau implique que les langages de haut niveaux (Java, Ada, Python, ...) ne sont pas du tout adaptés à l'écriture des systèmes d'exploitation.
Le langage le plus utilisé reste à ce jours le langage C : Linux, BSD, MacOS, Windows, ... sont tous écrits pour leur plus grande partie en C.

Vous avez normalement un cours de C en parallèle, et les TPs utiliseront le langage C. (La référence sur le langage C reste à mon goût le livre de Kernighan et Ritchie : « the C Programming language ». (Disponible en francais à la BU sous le titre « Le langage C : norme Ansi ».) Il existe de nombreux autres livres / documents sur la programmation C comme le [http://www-clips.imag.fr/commun/bernard.cassagne/Introduction_ANSI_C.html polycopié de Bernard Cassagne « introduction au langage C »].

Les premiers systèmes d'exploitation étaient écrits directement en langage machine, ou bien en langage d'assembleur ; et les systèmes actuels comportent encore quelques parties de très bas niveau en langage d'assemblage...

====Notion d'appel système, norme POSIX====

La programmation de haut niveau en C est assez différente de la programmation système. De nombreuses fonctions C utilisent en fait des « appels système », c'est à dire des appels de fonctionnalités propres du système d'exploitation. Les appels système typiques sont :
* les fonctions relatives aux fichiers (création, suppression, modification...)
* les fonctions relatives à la gestion de la mémoire
* les fonctions relatives aux processus (<tt>fork</tt>)
* ...

De nombreux système d'exploitation proposent une interface [http://en.wikipedia.org/wiki/Posix POSIX] (« '''P'''ortable '''O'''perating '''S'''ystem '''I'''nterface for Uni'''x''' »). Cette norme définit entre autres un ensemble de fonctions pour utiliser les appels systèmes.
Le nombre de ces fonctions est relativement faible : une centaine ; et chacune correspond en gros à un appel système. Certaines de ces fonctions ne sont pas définies directement dans le système d'exploitation, mais dans des librairies. Pour Linux, il s'agit en général de la librairie Glibc (GNU C Library).

Par exemple, la fonction <tt>open</tt> (qui permet d'ouvrir un fichier) correspond exactement à un appel système ; alors que la fonction <tt>malloc</tt> (qui permet d'allouer dynamiquement de la mémoire dans le tas) peut générer plusieurs appels système (<tt>brk</tt> et <tt>sbrk</tt>).

Pour visualiser les appels systèmes effectués par un programme sous Linux, vous pouvez utilisez l'utilitaire <tt>strace</tt> ou <tt>ltrace</tt>. Par exemple, dans le shell :
$ strace -e trace=file ls -l 2> trace
permet de récupérer tous les appels systèmes relatifs aux fichiers lors de l'appel à <tt>ls -l</tt>. La liste des appels système est redirigée dans le fichier <tt>trace</tt> qui contiendra par exemple des lignes telles que
lstat64("Desktop", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lgetxattr("Desktop", "security.selinux", 0x8cc08e0, 255) = -1 ENODATA (No data available)
dénotant ainsi un appel aux appels système <tt>lstat64</tt> et <tt>lgetxattr</tt>...

Les principaux systèmes compatibles POSIX sont :
* Linux
* BSD (et variantes)
* Mac OS X
* Solaris

De nombreux appels systèmes sont disponibles directement (sans avoir besoin d'écrire un programme C) à travers le shell. Exécuté dans un terminal, le shell permet, en première approximation, de passer directement des commandes au système d'exploitation. (La norme POSIX définit également un ensemble de fonctions du shell. Il est donc relativement aisé de changer de système d'exploitation tant qu'on reste dans les systèmes compatibles POSIX.)

Windows d'un autre côté utilise l'interface Win32 API, qui définit plusieurs milliers de fonctions. La plupart de ces fonctions peuvent utiliser plusieurs appels système...

Les systèmes d'exploitation qui utilisent l'API Win32 sont :
* Windows, depuis Windows95.

Il est possible d'installer un environnement compatible POSIX sur une machine Windows grâce à Cygwin. (C'est d'ailleurs fortement conseillé si vous ne voulez pas installer une version de Linux ou BSD sur votre ordinateur personnel...)

====Mode noyau / mode utilisateur====

La partie fondamentale du système d'exploitation est le ''noyau'' (''kernel'' en anglais). C'est la couche de plus bas niveau.

Les fonctionnalités de très bas niveau offertes par le noyau peuvent facilement planter l'ordinateur. Il faut donc une politique de restriction pour que tous les programmes ne puissent y accéder dans leur totalité. On parle de
* mode noyau
* mode utilisateur

Dans le mode utilisateur, on ne peut accéder à ces fonctionnalités qu'a travers les appels systèmes ; dans le mode noyau, on peut tout faire... Bien entendu, un appel système doit passer momentanément en mode noyau pour pouvoir exécuter les commandes pertinentes, puis il repasse automatiquement en mode utilisateur.

La définition d'un appel système pourrait donc être « fonctionnalité atomique nécessitant un passage en mode noyau ».

====Noyau, noyau monolithique, micro-noyau====

La partie principale du système d'exploitation. C'est lui qui gère les ressources, les entrées / sorties, la communication entre processus, ... Les deux architectures principales pour un noyau sont :
* noyau monolithique
* micro-noyau
La plupart des systèmes actuels sont basés sur un noyau monolithique (Linux, BSD, Mac OS X, Solaris, Windows).

Les noyaux monolithiques sont parfois décrits comme « sans vraie structure » : une grosse soupe où cohabitent toutes les fonctionnalités du système d'exploitation. L'idée d'avoir un système unique qui gère tout est effectivement peu attirante et peut poser quelques problèmes de génie logiciel...
Un noyau monolithique est donc la couche entre le matériel et les programmes utilisateurs. Pour éviter de compiler des noyaux énormes, les noyaux monolithiques actuels utilisent en plus la notion de ''module''. Ce sont des morceaux du noyau qu'on peut charger ou décharger au besoin. Si l'interface est connue, ces modules peuvent éventuellement être en binaire, ce qui permet d'utiliser des modules propriétaires avec un noyau libre.
Sous Linux, la commande
$ lsmod
permet d'obtenir la liste des modules chargés dans le noyau.

Les micro-noyaux d'un autre coté sont basés sur la remarque que seule une toute petite partie du noyau accède effectivement au matériel. Seule cette petite partie nécessite donc des privilèges et effectue des appels système. Le reste du système d'exploitation peut être programmé en mode utilisateur, « au dessus » de cette partie. Par exemple, le micro noyau offrira la possibilité de charger un nouveau processus, mais l'ordonnanceur (qui choisit quel processus devra être chargé) ne fera pas partie du micro-noyau. On parle parfois de ''services'' / ''serveurs'' au dessus du micro-noyau.
Ceci permet d'avoir un noyau bas niveau beaucoup plus petit. Bien que ceci soit une bonne idée, et que les micro-noyaux puissent fournir de meilleurs garanties de sécurité, peu de noyaux sont effectivement des micro-noyaux. Un des problèmes est qu'un tel micro-noyau est un peu plus lent que ses cousins monolithiques. La raison principale est que dans le cas d'un micro-noyau, un appel système nécessite en fait des communications inter-processus.
Andrew Tanenbaum est un fervent défenseur des micro-noyaux.

Une autre architecture possible est d'utiliser des couches successives, chacune avec des privilèges réduits. Le système Multics avait cette architecture.
Par exemple, dans le système THE (1965), les couches étaient les suivantes :
# noyau bas niveau, multiprogrammation
# allocation de la mémoire pour les processus
# IPC (communication inter processus)
# entrées / sorties (buffer, etc.)
# programmes utilisateurs (compilation, exécution, ...)
# utilisateur (Dijkstra a annoté la description de cette couche par ''« not implemented by us »'')

Une dernière catégorie de noyau est la catégorie des machines virtuelles. Ces noyaux sont un peu à part, car il s'agit d'émuler un système d'exploitation ou du matériel particulier à l'intérieur d'un autre système d'exploitation ou matériel. Le mode noyau de la machine virtuelle est en fait dans le mode utilisateur du noyau original...

==Les processus==

===Introduction===

Allez hop commençons par une petite définition du type wikipédia :

Un processus (en anglais, process), en informatique, est défini par :
* un ensemble d'instructions à exécuter (un programme) ;
* un espace mémoire pour les données de travail ;
* éventuellement, d'autres ressources, comme des descripteurs de fichiers, des ports réseau, etc.

Un ordinateur équipé d'un système d'exploitation à temps partagé est capable d'exécuter plusieurs processus de façon « quasi- simultanée ». Par analogie avec les télécommunications, on nomme multiplexage (A. Tanenbaum parle de ''multiprogrammation'') ce procédé. S'il y a plusieurs processeurs, le système essaie de répartir les processus de manière équitable sur les processeurs disponibles.

Le processus doit être imaginé comme quelque chose qui prend du temps, donc qui a un début et (parfois) une fin. De nombreux processus ne se terminent normalement jamais : système d'exploitation, serveurs web, serveurs mail, ... D'autres processus plus légers qui ne se terminent pas sont les ''daemon'' (acronyme ''a posteriori'' de "disk and execution monitor") du monde Unix.

Certains processus sont démarrés très tôt lors de la séquence de boot. Le système d'exploitation est un tel processus. Sinon, les processus sont normalement démarrés grâce à un appel système à partir d'un autre processus. L'utilisateur peut par exemple demander explicitement un nouveau processus (sous POSIX, grâce à un <tt>fork</tt> puis <tt>exec</tt>) ; mais la plupart du temps, il le fera à travers une application, par exemple en double-cliquant sur l'icône d'un programme dans l'explorateur de fichiers.

Le système d'exploitation est chargé d'allouer les ressources (mémoires, temps processeur, entrées/sorties) nécessaires aux processus et d'assurer que le fonctionnement d'un processus n'interfère pas avec celui des autres (isolation).

Pas sûr d'avoir tout compris ? Ce n'est pas grave, essayons autrement.
:'''Définition :''' un processus est un programme en train de s'exécuter.
Cette définition implique en particulier que un programme (navigateur Firefox par exemple) peut correspondre à
* zéro processus si on ne l'a pas lancé,
* un processus si on l'a lancé,
* plusieurs processus si on l'a lancé plusieurs fois.
(''Remarque :'' pour un programme comme Firefox, il y a fort à parier que l'exécution d'une seule instance de Firefox génère de multiples sous-processus...)

Que se passe-t-il quand je démarre une application?

:L'ordinateur à une nouvelle tâche à accomplir, les instructions correspondantes sont donc envoyées au processeur. Comme il a plusieurs choses à faire le choix des instructions à exécuter n'est pas forcement simple. Il faut faire en sorte de partager le processeur entre les différentes tâches de manière équitable : c'est la fameuse gestion des processus.
:Ceci permet de réaliser plusieurs activités en ~même temps~. Grâce à la gestion des processus on peut regarder un film (obtenu par des moyens tout à fait légaux cela va de soit), tout en jouant à la dame de pique.
:(et dire que certain(e)s affirment que l'homme est mono tâche)

Plusieurs processus indépendants peuvent être ''actifs'' en même temps, mais sauf si l'ordinateur possède suffisamment de processeurs, on ne peut pas les exécuter simultanément. L'impression que plusieurs programmes s'exécutent ''en même temps'' vient simplement du fait que le processeur alterne rapidement entre eux.
Comme le temps d'exécution d'une instruction par le processeur est très court, de l'ordre de la nano-seconde, le processeur peut réaliser plusieurs centaines de millions d'instructions par seconde. Ainsi, une tranche de temps de quelques fractions de seconde, partagée entre plusieurs processus, donne à l'échelle macroscopique l'illusion de la simultanéité.

'''En résumé :''' un système d'exploitation doit la plupart du temps traiter plusieurs tâches en même temps, et comme il n'a, en général, qu'un seul processeur, il devra contourner ce problème grâce à un pseudo-parallélisme. Il traite une tâche à la fois, s'interrompt et passe à la suivante. La commutation de tâches étant très rapide, il donne l'illusion d'effectuer un traitement simultané.

===La table des processus===

L'information sur les processus est conservé par le système dans une structure de données appelée ''table des processus''. Cette table contient toutes les informations nécessaires à la gestion des processus :
* état du processus
* PID
* droits
* répertoire de travail
* pointeur vers la pile
* priorités
* ...

Sous Linux, on peut accéder à ces informations à travers le système de fichiers virtuel "Procfs". Il suffit d'aller dans le répertoire <tt>/proc/</tt>.

===Création d'un processus===

Pour les système POSIX, la création d'un processus est très simple : on utilise la fonction <tt>fork()</tt>. En C, le prototype de la fonction se trouve dans le fichier d'entêtes <tt>unistd.h</tt>.

Cette fonction prend 0 argument et permet de faire la chose suivante : elle crée un nouveau processus qui est une copie conforme du processus appelant. La seule différence visible entre l'ancien et le nouveau processus est que les processus ont un numéro (PID) différent. Pour le processus appelant, il peut obtenir le PID du nouveau processus en regardant la valeur de retour de <tt>fork</tt>. Pour le nouveau processus, cette valeur vaudra 0, et il devra utiliser la fonction <tt>getpid()</tt> pour obtenir son numéro.

Le processus appelant est appelé le ''père'' alors que le nouveau processus est appelé le ''fils''.

Notez que l'espace mémoire du processus est dupliqué plutôt que partagé. Ceci veut dire que les processus ne peuvent pas communiquer en utilisant leur variables... Par contre, les descripteurs de fichiers du fils sont hérités directement de ceux du père ; ils peuvent donc essayer de communiquer en passant par ces fichiers. (Mais cela pose de nombreux problèmes de synchronisation.)

Voici par exemple un petit programme C qui lance un processus fils:
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {

int pid ;
int pid_fils ;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
} else {
printf(" >> Je suis le fils.\n");
}

return(0);

}
Après compilation, voici un exemple d'exécution du programme résultant :
$ ./pere_fils
> Le processus 8248 démarre...
>> Je suis le fils.
>> Je suis le père (pid du fils = 8249).

Voici un autre exemple d'exécution :
$ ./pere_fils
> Le processus 8269 démarre...
>> Je suis le père (pid du fils = 8270).
>> Je suis le fils.

Notez que les numéros sont différents, et que l'ordre d'affichage n'est pas le même. Cela vient de l'ordonnancement des deux processus qui peut différer.

La technique consistant à faire
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
...
}
montre que malgré le fait que les processus soient identiques à l'origine, on peut faire beaucoup de chose.

:'''Remarque :''' <tt>fork()</tt> n'est pas directement un appel système, mais une fonction qui utilise l'appel système <tt>clone()</tt>. Cet appel système ne fait pas partie de la norme POSIX...

La deuxième technique utilisée dans les systèmes POSIX consiste à utiliser <tt>fork()</tt> pour dupliquer le processus, puis à complètement remplacer le fils par un nouveau processus. La fonction correspondante est la fonction <tt>execv</tt> :
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
execv("/usr/bin/...", argv);
...
}
La fonction <tt>execv</tt> prend 2 arguments : une chaîne contenant le chemin d'accès à un programme, et un tableau d'arguments à donner au programme. (C'est un peu plus compliqué que ça : le premier élément du tableau est le nom du programme, et le tableau doit se terminer par un pointeur NULL.)

Une dernière fonction importante est la fonction <tt>wait(pid)</tt> qui permet à un processus d'attendre l'arrêt du processus <tt>pid</tt>.

-- ...

L'API WIN32 possède de nombreuses fonctions avec des fonctionnalités similaires. Par exemple, la fonction [http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx <tt>CreateProcess</tt>] permet de créer un nouveau processus (comme un <tt>fork</tt> suivi d'un <tt>exec</tt>), mais elle nécessite ... 10 arguments !

----

Un autre moyen de créer des processus est d'utiliser des 'processus légers' appelés Thread. Ces processus légers partage seulement une partie de la mémoire, ce qui en pratique est plus rapide pour simuler un parallélisme. On passe alors par une autre fonction. Sous GNU/Linux, lors de l'écriture d'un programme écrit en C il faut utiliser la bibliothèque pthread.h et lors de la compilation, faire un lien vers celle ci, en utilisant le paramètre -lpthread.

====Arborescence des processus dans les systèmes POSIX====

Nous avons vu que la fonction <tt>fork()</tt> permet de créer un processus fils. Le père connaît le PID de son fils : il lui est donné par la fonction <tt>fork()</tt>. Comme le fils peut lui même créer des processus fils, on obtient rapidement une arborescence de processus.

Vous pouvez visualiser cette arborescence à partir d'un terminal avec la commande <tt>pstree</tt> (l'option <tt>-p</tt> permet de demander l'affichage des PID)
$ pstree -p
init(1)─┬─acpid(25425)
├─atd(14365)
├─console-kit-dae(3632)─┬─{console-kit-dae}(3633)
│ ├─{console-kit-dae}(3641)
...
├─cron(14315)
├─dbus-daemon(15590)
├─dbus-daemon(3511)
...
├─getty(4095)
├─getty(4096)
├─getty(4097)
├─getty(4098)
├─getty(4099)
├─gpm(3528)
...
├─kded4(15769)
├─kdeinit4(15766)───klauncher(15767)
├─kdm(15564)─┬─Xorg(15566)
│ └─kdm(15573)───sh(15608)─┬─conky(15751)
│ ├─fluxbox(15703)───firefox-bin(6063)─┬─{firefox-bin}(6064)
│ │ ├─{firefox-bin}(6065)
...
│ ├─ssh-agent(15698)
│ ├─unclutter(15742)
│ ├─wicd-client(15749)
│ └─xscreensaver(15683)
...
├─rsyslogd(6850)─┬─{rsyslogd}(6140)
│ └─{rsyslogd}(6141)
├─screen(4427)─┬─bash(4428)───pstree(9307)
│ ├─bash(4429)───man(7952)───pager(7965)
│ ├─bash(4430)───vi(30568)
│ ├─bash(18395)───vi(28512)
│ └─mutt(8763)
...

Le processus <tt>init</tt> est l'ancêtre de tout les processus, il a toujours 1 comme PID.

'''Remarque :''' sous Windows, les processus ne sont pas organisé en arborescence...

====Mort d'un processus dans un système POSIX====

Un processus peut se terminer pour plusieurs raisons :
* volontairement, grâce à la fonction <tt>exit()</tt> (POSIX) ou <tt>ExitProcess()</tt> (Windows),
* à cause d'une erreur,
* en recevant un signal d'un autre processus, grâce à la fonction <tt>kill()</tt> (POSIX) ou <tt>TerminateProcess()</tt> (Windows).

Lorsqu'un processus se termine, plusieurs choix sont possibles :
* que fait-on de ses fils ?
* que fait-on de son père ?

Linux fait la chose suivante : quand un processus s'arrête,
* tous ces fils s'arrêtent,
* son père reçoit un signal le prévenant que son fils vient de mourir.

Pour que le père puisse recevoir le signal correspondant, il faut qu'il utilise la fonction <tt>wait()</tt> ou <tt>waitpid()</tt>. Tant que le parent existe et qu'il n'a pas reçu le signal disant qu'un de ces fils est mort, le processus fils n'est pas entièrement supprimé : il devient un ''zombie''. (Il n'occupe plus vraiment de place en mémoire, mais le système garde juste suffisamment d'information pour pouvoir prévenir le père si celui ci demande l'état du fils.)

'''Remarque :''' les processus Windows ne sont pas organisés sous forme d'arborescence. Chaque processus peut surveiller l'état d'un autre processus, s'il connaît son PID. Il n'y a donc pas de notion de processus ''zombie'' sous Windows.

Voici un petit programme C qui crée un processus fils, ne fait rien pendant 20 secondes, puis demande l'état de son fils :
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
int pid ;
int pid_fils ;
int w;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
printf(" >> Je suis le père et j'attends un peu.\n");
sleep(20);
printf(" >> Je suis le père et je demande l'état de mon fils.\n");
wait(&w);
printf(" >> Mon fils est mort (signal %i).\n", w);
while(1) sleep(1);
} else {
printf(" >> Je suis le fils.\n");
while (1) sleep(1);
exit(0);
}
return(0);
}
Si on tue le processus fils pendant que le père ne fait rien, le processus fils devient un zombie. Dès que le père fait le <tt>wait</tt>, il reçoit la valeur du signal qui a terminé le processus et le zombie disparaît.

Si on ne tue pas le processus fils, le père n'exécutera jamais le <tt>printf(" >> Mon fils est mort...);</tt>.

'''Remarque :''' dans un système POSIX, lorsqu'un processus meurt, ses fils deviennent ''orphelins''. Il continuent leur exécution mais sont adopté par <tt>init</tt> (PID : 1). Dans certains cas lorsque le processus est arrêté, il envoie explicitement un signal <tt>SIGTERM</tt> pour tuer ses processus fils. C'est par exemple ce qui arrive lorsqu'on lance des application à partir d'un terminal et que l'on quitte le terminal en question...

===États d'un processus===

On peut imaginer un SE dans lequel les processus pourraient être dans trois états :
* en cours d'exécution,
*bloqué : il attend un événement extérieur pour pouvoir continuer (par exemple une ressource; lorsque la ressource est disponible, il passe à l'état "prêt")
*prêt : suspendu provisoirement pour permettre l'exécution d'un autre processus.

Dans un système avec un unique processeur, au plus un processus peut se trouver dans l'état ''en cours d'exécution''. Par contre, il peut y avoir de nombreux processus dans l'état ''bloqué'' ou dans l'état ''prêt''.

Un processus peut passer d'un état à l'autre :
# de ''en exécution'' à ''bloqué'' lorsqu'une ressource n'est pas disponible (entrées / sortie par exemple),
# de ''bloqué'' à ''prêt'' si la ressource ayant provoqué le blocage devient disponible,
# de ''en exécution'' à ''prêt'' si le système décide de suspendre l'exécution du processus,
# de ''prêt'' à ''en exécution'' si le système décide de lancer l'exécution du processus.

On peut résumer ceci par le graphe de transitions suivant :

[[Image:Diagrammedétatdunprocessus.png]]

Les transition manquantes ne sont pas possible directement mais doivent passer par des transition intermédiaires.

On peut ajouter 2 états :
* ''nouveau'' pour un processus qui vient d'être créé,
* ''terminé'' pour un processus qui vient de se terminé.

Dans les systèmes type ''ordinateur de bureau'', le passage de ''nouveau'' à ''prêt'' est automatique mais dans des systèmes temps réel, un processus peut parfois attendre dans cet état.

L'état ''terminé'' est en général passager. Par exemple, lorsqu'un processus terminé est un zombie, le processus n'est conservé que dans la table des processus. La mémoire utilisé par le processus est libérée. La question de savoir si ceci est véritablement un état du processus est donc essentiellement une question de vocabulaire.

:exercice : ajouter les états ''nouveau'' et ''terminé'' et les transitions correspondantes au graphe précédent. Identifiez des situations provoquant les transitions possibles entre états.

===Ordonnancement des processus===

Nous avons vu qu'il pouvait y avoir de nombreux processus dans la table de processus (environ 150 sur mon ordinateur en ce moment même). Parmi ces processus, un seul (sur une machine à un processeur) peut se trouver dans l'état ''en exécution''. C'est au système d'exploitation de décider qui, à un moment donnée, doit se trouver dans cet état. La partie du système faisant ceci s'appelle ''ordonnanceur'' (ou ''scheduler'' en anglais).
En utilisant le contenu de la table des processus et éventuellement d'autres information, ordonnanceur doit donc gérer les transition entre états de tous les processus, et envoyer l'information nécessaire aux composants adéquat du noyau.

Comme d'habitude, l'ordonnanceur doit faire des compromis entre :
* la vitesse,
* l'utilisation de la mémoire,
* l'optimalité de la solution proposée.

'''Remarque : ''' l'ordonnanceur est lui même un processus (ou un morceau de processus dans le cas des noyaux monolithiques).

====Ordonnancement non préemptif====

'''FIFO.'''
L'algorithme d'ordonnancement le plus facile est probablement celui de type ''FIFO'' : premier arrivé, premier servi. Autrement dit, on préempte premier processus arrivé, et on l'exécute jusqu'à la fin. La seul structure de donnée est donc simplement une ''file''.

'''Plus court temps d'exécution.'''
Dans certain cas, on peut prévoir a l'avance le temps processeur dont aura besoin un processus pour s'exécuter. On peut alors choisir le processus le plus court et l'exécuter en premier. Ceci a en général tendance à diminuer le temps d'attente moyen d'un processus ; mais si des processus courts sont crées régulièrement, on peut assister à une ''famine'' : un processus peut ne jamais s'exécuter.

:exercice : trouver une suite de processus qui provoque une famine.

Ces deux exemples sont acceptables pour un ''traitement par lots'' (batch) par exemple pour des calculs numériques. Ils ne sont par contre pas du tout adaptés pour un ordinateur personnel ou un système temps réels. (Pas de ''multiprogrammation''.)

====Ordonnancement préemptif====

Pour pouvoir donner l'illusion de simultanéité, les processus sont en général exécutés par tranches de temps spécifiées à l'avance (''time slice'' en anglais). Au bout de ce temps, le noyau reçoit une interruption et examine les processus. Il peut décider de continuer le processus courant, ou bien le remplacer par un autre processus. on parle de préemption.

Windows 3.1 ou MacOS 9 étaient des systèmes ''collaboratifs'' car les processus devaient explicitement laisser la main aux autres processus. Tous les systèmes d'exploitation modernes sont maintenant préemptifs. On parle maintenant de système préemptif lorsque la préemption peut s'effectuer même sur des processus en mode noyau.
On parle parfois de noyau préemptible lorsque que les opérations en mode noyau sont elle même préemptibles.

'''Tourniquet.'''
L'algorithme le plus simple est probablement celui du tourniquet (''round Robin'' en anglais). C'est une variante de l'algorithme FIFO vu plus haut, mais qui préempte le processus courant au bout d'un moment. Si ce processus est encore en exécution, on le remet à la fin de la file des processus.

Le temps imparti à chaque processus ne doit pas être trop court (sinon, le changement de contexte prend trop de temps par rapport à l'exécution des processus) ni trop long (sinon, on perd l'illusion de parallélisme, et un processus bloqué risque d'occuper le processeur pendant trop longtemps).

Voici ce qu'on peut trouver dans le livre "Understanding the Linux kernel" :

<cite>
The choice of quantum duration is always a compromise. The rule of thumb adopted by Linux is: choose a duration as long as possible, while keeping good system response time.
</cite>

(extrait du chapitre [http://oreilly.com/catalog/linuxkernel/chapter/ch10.html "Process Scheduling"]).

'''Tourniquet avec priorité.'''
Tous les processus ne naissent pas égaux : certains ont une importance plus élevée (les processus systèmes par exemple). Dans un cas comme le précédent, tous les processus ont le même statut...
Pour corriger ce problème, on utilise parfois un algorithme similaire, mais on choisit le premier processus de priorité la plus élevé possible. Plutôt que de parcourir la file à sa rechercher, on utilise en fait plusieurs files : une pour chaque priorité.

Il faut faire attention car les processus de priorité basse risquent de ne jamais être exécutés (famine)... Par exemple, on peut diminuer petit à petit la priorité des processus qu'on exécute...

Une autre solution pour gérer les priorité en évitant certaines famines est d'exécuter toutes les files, mais pas en proportion égale. Par exemple, on choisit un processus dans les piles de priorité 1, 2, 1, 3, 1, 2, 1, 4, 1, 2, 1, 3, 1, 2, 1, ... De cette manière, les processus de la première file sont exécutés 2 fois plus de fois que ceux de la file 2, et 4 fois plus de fois que ceux de la file 3.

:exercice : donnez un algorithme pour générer la suite précédente pour un nombre donné de files. Il faut que la file ''i'' soit utilisée 2 fois plus souvent que la pile ''i+1''.

'''Répartition garantie.'''
Chaque tache reçoit la même proportion du processeur, et chaque utilisateur reçoit la même proportion également.

'''tirage aléatoire.'''
À chaque étape, on tire un "billet" au hasard, et le processus qui a le "billet gagnant" s'exécute.

Principe de priorité : Les processus qui ont été définit comme prioritaire on plus de "billet" à leur nom et ont donc plus de chance d'être tiré.

''NB : POSIX définit une commande "nice" qui permet e donner à un processus un priorité plus faible (et par conséquent, nice -x augmente cette priorité). Il est évident que tout le monde ne doit pas pouvoir utiliser cette commande, il vaut mieux que l'administrateur se réserve ce droit''

'''Ordonnancement équitable.'''

==La mémoire==

===Introduction===

RAM = Random Acces Memory. C'est ce que l'on appelle couramment la mémoire vive, elle peut être modifié à l'infini et sert à stocker temporairement les fichiers que l'ordinateur exécute.

ROM = Read Only Memory. On l'appelle aussi mémoire fixe ou mémoire morte, dès que l'on enregistre, le contenu d'une mémoire ROM ne peut pas être modifié (ex: un CD-ROM).

'''Gestion de la mémoire : '''

Lors du boot du PC, le système est chargé en mémoire.
Tout processus créé est aussi chargé dans la mémoire.

Lorsque l'on créé uns seul processus, il est plus pratique de le charger en "bas" de la mémoire, à partir de la première case de l'espace mémoire. Puis les nouveaux processus peuvent être charger par dessus. Ainsi la machine comprend où commence l'espace mémoire.

Problèmes :
1 - l'espace d'adressage ne commence pas à 0;
2 - un processus peut demander dynamiquement de la mémoire;
3 - avec un accès direct, un processus peut faire "planter" un autre.

==> Il faut avoir une couche d'abstraction au-dessus de la mémoire physique.

===Espaces d'adressage===

Et si l'on créait des espaces d'adressage distincts pour chaque processus ?
Par exemple : chaque processus utilise des adresse de 0 à n de la mémoire, on converti alors ces adresses en adresses physiques.

Certains des premiers processeurs avaient deux registres supérieurs :

- une Base => adresse physique du début de l'espace d'adressage

- une Limite => adresse physique de fin de l'espace d'adressage

Par exemple, lors de l'exécution d'un processus l'accès à une case "a" se transforme en l'accès à la Base+a et un test pour vérifier que : a+Base < Limite.

Malgré tout, ceci ne résout pas les problèmes liés au fait que des processus sont créés et disparaissent, réclament ou libèrent de la mémoire.

===Va-et-vient (swapping)===

====Idée====

Et si pour gérer tout cela on utilisait une mémoire auxiliaire (disque), pour stocker l'état de la mémoire de processus.

La mémoire vue par les processus ne correspond pas à la mémoire physique. À un instant donné, certains processus peuvent se retrouver sur le disque (dans le SWAP).

Quand un processus apparait, on lui cherche un morceau d'espace libre dans la mémoire.

====gestion de la mémoire====

* tableau de bits
* liste chaînée

====Allocation====

* first fit
* next fit
* best fit
* worst fit

===Mémoire virtuelle===

====Idée====

====Pagination====

====Traduction des adresses====

====Table des pages====

====Table inversée====

====Remplacement des pages====

==Les entrées / sorties==

----
----

==Références==

* le livre « Systèmes d'exploitation » de Andrew Tanenbaum est disponible à la BU
* la page du [http://sos.enix.org/fr/PagePrincipale projet SOS]
* la [http://www.opengroup.org/onlinepubs/009695399/nfindex.html norme POSIX:2004]
* l'[http://msdn.microsoft.com/en-us/library/aa383749(VS.85).aspx API win32]
* [http://www.lemis.com/grog/Documentation/Lions/index.php Commentary on the Sixth Edition UNIX Operating System]

INFO502 : Systèmes d'exploitation

2009-12-04T12:53:58Z

Hatat : /* TP */ Ajout du lien vers SOS article 5

Ce wiki est un complément de cours pour le cours « info-502 : systèmes d'exploitation ». La participation au wiki est fortement encouragée.

Pour pouvoir modifier les pages, inscrivez-vous (lien en haut à droite) pour obtenir un login et mot de passe. (Choisissez un login du style ''PrenomNom''...)

Je vous conseille d'aller lire [http://meta.wikimedia.org/wiki/Aide:Contenu ce guide] pour vous familiariser avec les wikis.

Exercice : si vous n'en avez pas, créez-vous un compte et essayez de modifier cette page (correction de fautes d'hortographe, rajout de détails, mise en page, ...)

Vous pouvez aussi utiliser la page de discussion pour ... discuter. (Ou poser des questions, faire des commentaires etc.)

----
----
==Auteur du cours==

===Nouvelles===

===Supports===

====TD====

Sujets de TD :
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td1.pdf Ordonnancement],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td2.pdf Gestion de la mémoire],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td3.pdf Systèmes de fichiers].

====TP====

# Découverte de SOS :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp1.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp1.tar.gz code source].
# Gestion de la mémoire du noyau :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp2.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp2.tar.gz code source],
#* Article [http://sos.enix.org/wiki-fr/upload/SOSDownload/sos-texte-art5.pdf Gestion de la mémoire virtuelle du noyau]

==Introduction==

-- ...

==Repères historiques==

Voici quelques évènements clés dans l'histoire des systèmes d'exploitation. Pour plus de détails, ou pour des compléments sur l'histoire de l'informatique, je vous renvoie sur Wikipedia : [http://en.wikipedia.org/wiki/History_of_operating_systems "History of operating systems"] et [http://en.wikipedia.org/wiki/History_of_computing "History of computing"].

Les premiers ordinateurs ne comportaient pas vraiment de système d'exploitation : c'étaient des opérateurs humains qui géraient tout. (C'était juste après la seconde guerre mondiale, l faut savoir que les langages de programmation n'existaient même pas...) La petite histoire (??) raconte qu'à un moment, les processus pour l'ordinateur de l'université de Cambridge étaient accrochés sur une corde à linge et que c'était la couleur des pinces à linges qui donnait la priorité. (??)

Le passage à la notion de système d'exploitation c'est faite graduellement pour répondre à la complexité de plus en plus grande des ordinateurs et aux demandes des utilisateurs.

Les premier systèmes d'exploitation datent probablement de 1956. Ils permettaient simplement d'exécuter un nouveau programme lorsque le précédent était terminé. Les ordinateurs d'IBM de la famille System/360 ont ensuite eu toute une série de systèmes d'exploitation plus ou moins similaires : OS/360, DOS/360 (rien à voir avec MS-DOS), TSS/360... C'est à cette époque qu'est apparu la notion de multiprogrammation (possibilité d'avoir plusieurs processus entrelacés.)
C'est également au début des années 60 qu'on a commencé à voir des systèmes avec temps partagé : plusieurs utilisateurs pouvaient utiliser un ordinateur. Le système Multics a été, à ce niveau comme à d'autres, assez révolutionnaire. Multics a été utilisé jusqu'en 2000 !

Multics n'était par contre pas approprié pour les mini-ordinateurs où le nombre d'utilisateur est relativement restreint. En 1969, Ken Thomson
a développé une variante simplifié de Multix : Unix...

Ce n'est qu'un peu plus tard (1979) que la première version de DOS (86-DOS ou QDOS) apparaît. 86-DOS sera racheté par Microsoft un 1980...

'''Liens et compléments :'''
* [http://en.wikipedia.org/wiki/Timeline_of_operating_systems Timeline of operating systems]
* généalogie des systèmes Unix : [http://www.levenez.com/unix/ Unix History]
* généalogie de Windows : [http://www.levenez.com/windows/ Windows History]
* généalogie des systèmes non-Unix : [http://www.oshistory.net/metadot/index.pl?id=2165 timeline of non-Unix operating systems]

==Vue d'ensemble==

Ce cours reste assez généraliste et essaie de regarder les principales fonction d'un système d'exploitation. Les systèmes de type Unix (Linux) sera un exemple privilégié. À cause de leur complexité intrinsèque, les évolutions modernes (architectures multicoeur ou multiprocesseur, ...) seront en partie ignorée dans un premier temps.

Les problèmes fins de communication entres processus ne seront que très peu abordés, car ils font l'objet d'un cours séparé (info604) pour la filière info.

Nous allons suivre l'ordre classique consistant à regarder :
# les processus
# la mémoire
# les entrées / sorties

La fin du cours dépendra du temps restant...

===Les processus===

Un processus est simplement un programme « en exécution ». À tout instant, un ordinateur de bureau contemporain contient de nombreux processus qui doivent partager le (les) processeur(s) pour donner l'impression qu'ils s'exécutent « en même temps ». Un des rôles du système d'exploitation consiste à décider dans quel ordre les processus vont effectivement pouvoir utiliser le processus.

===La mémoire===

La mémoire est, comme le processeur, une ressource partagée par les différents processus. Il faut donc gérer la quantité de mémoire allouée et utilisée pour que les processus n'aient pas à s'occuper de ceci. Un des concepts fondamentaux est celui de mémoire virtuelle. Ceci permet d'offrir un espace mémoire pour chacun des processus de manière transparente.

===Les entrées / sorties===

Un ordinateur n'est pas (plus) un système indépendant du reste du monde : il interagit avec l'extérieur à travers des périphériques d'entrées/sorties (clavier / écran / souris / ...). La gestion de ces périphériques pose un ensemble de problèmes que nous aborderons brièvement...

===...===

Une fois ces notions vues, nous regarderons peut-être les problèmes de sécurité, de multimédia ou des architectures multiprocesseurs.

==Préliminaires==

===Quoi ?===

Les ordinateurs, ou plus simplement les micro contrôleurs sont des circuits électroniques avec une puce « processeur ». Le développement d'applications n'est pas facile si on se place au niveau électronique et que l'on parle directement au CPU. Pour faciliter la vie des programmeurs, plusieurs couches d'abstraction sont nécessaires. La première se place au niveau matériel et s'occupe directement des problèmes électroniques ou de très bas niveau. Il s'agit du ''firmware''. Il répond par exemple aux questions comme :
* qu'elle est l'amplitude des signaux envoyés par l'horloge ?
* est-ce que l'UC possède un pipeline ?
* ...
Un firmware est donc forcement très lié au matériel sur lequel il tourne.

La couche suivante est le système d'exploitation à proprement parler. Dans le cas que vous connaissez le mieux (ordinateur personnel), le système d'exploitation fournit une interface pour :
* exécuter un programme
* exécuter plusieurs programmes « en même temps »
* gérer les ressources (temps processeur, mémoire disponible, entrées / sorties)
* les opérations sur les fichiers
* offrir des garanties de sécurité

===Où ?===

On trouve des systèmes d'exploitation partout :

* dans les ordinateurs personnels (Linux, BSD, MacOS, Solaris, Windows, ChromeOS (?))
* dans les PDA (PalmOS, ...)
* dans les téléphones portables (Android, OpenMoko,Symbian,)
* console de jeux
* lecteur MP3 (Rockbox, ...)
* les microcontroleurs « avancés »

===Comment ?===

====Langage de programmation====

Le système d'exploitation se situe entre le firmware (très bas niveau) et l'utilisateur. La nécessité d'accéder à ces ressources de très bas niveau implique que les langages de haut niveaux (Java, Ada, Python, ...) ne sont pas du tout adaptés à l'écriture des systèmes d'exploitation.
Le langage le plus utilisé reste à ce jours le langage C : Linux, BSD, MacOS, Windows, ... sont tous écrits pour leur plus grande partie en C.

Vous avez normalement un cours de C en parallèle, et les TPs utiliseront le langage C. (La référence sur le langage C reste à mon goût le livre de Kernighan et Ritchie : « the C Programming language ». (Disponible en francais à la BU sous le titre « Le langage C : norme Ansi ».) Il existe de nombreux autres livres / documents sur la programmation C comme le [http://www-clips.imag.fr/commun/bernard.cassagne/Introduction_ANSI_C.html polycopié de Bernard Cassagne « introduction au langage C »].

Les premiers systèmes d'exploitation étaient écrits directement en langage machine, ou bien en langage d'assembleur ; et les systèmes actuels comportent encore quelques parties de très bas niveau en langage d'assemblage...

====Notion d'appel système, norme POSIX====

La programmation de haut niveau en C est assez différente de la programmation système. De nombreuses fonctions C utilisent en fait des « appels système », c'est à dire des appels de fonctionnalités propres du système d'exploitation. Les appels système typiques sont :
* les fonctions relatives aux fichiers (création, suppression, modification...)
* les fonctions relatives à la gestion de la mémoire
* les fonctions relatives aux processus (<tt>fork</tt>)
* ...

De nombreux système d'exploitation proposent une interface [http://en.wikipedia.org/wiki/Posix POSIX] (« '''P'''ortable '''O'''perating '''S'''ystem '''I'''nterface for Uni'''x''' »). Cette norme définit entre autres un ensemble de fonctions pour utiliser les appels systèmes.
Le nombre de ces fonctions est relativement faible : une centaine ; et chacune correspond en gros à un appel système. Certaines de ces fonctions ne sont pas définies directement dans le système d'exploitation, mais dans des librairies. Pour Linux, il s'agit en général de la librairie Glibc (GNU C Library).

Par exemple, la fonction <tt>open</tt> (qui permet d'ouvrir un fichier) correspond exactement à un appel système ; alors que la fonction <tt>malloc</tt> (qui permet d'allouer dynamiquement de la mémoire dans le tas) peut générer plusieurs appels système (<tt>brk</tt> et <tt>sbrk</tt>).

Pour visualiser les appels systèmes effectués par un programme sous Linux, vous pouvez utilisez l'utilitaire <tt>strace</tt> ou <tt>ltrace</tt>. Par exemple, dans le shell :
$ strace -e trace=file ls -l 2> trace
permet de récupérer tous les appels systèmes relatifs aux fichiers lors de l'appel à <tt>ls -l</tt>. La liste des appels système est redirigée dans le fichier <tt>trace</tt> qui contiendra par exemple des lignes telles que
lstat64("Desktop", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lgetxattr("Desktop", "security.selinux", 0x8cc08e0, 255) = -1 ENODATA (No data available)
dénotant ainsi un appel aux appels système <tt>lstat64</tt> et <tt>lgetxattr</tt>...

Les principaux systèmes compatibles POSIX sont :
* Linux
* BSD (et variantes)
* Mac OS X
* Solaris

De nombreux appels systèmes sont disponibles directement (sans avoir besoin d'écrire un programme C) à travers le shell. Exécuté dans un terminal, le shell permet, en première approximation, de passer directement des commandes au système d'exploitation. (La norme POSIX définit également un ensemble de fonctions du shell. Il est donc relativement aisé de changer de système d'exploitation tant qu'on reste dans les systèmes compatibles POSIX.)

Windows d'un autre côté utilise l'interface Win32 API, qui définit plusieurs milliers de fonctions. La plupart de ces fonctions peuvent utiliser plusieurs appels système...

Les systèmes d'exploitation qui utilisent l'API Win32 sont :
* Windows, depuis Windows95.

Il est possible d'installer un environnement compatible POSIX sur une machine Windows grâce à Cygwin. (C'est d'ailleurs fortement conseillé si vous ne voulez pas installer une version de Linux ou BSD sur votre ordinateur personnel...)

====Mode noyau / mode utilisateur====

La partie fondamentale du système d'exploitation est le ''noyau'' (''kernel'' en anglais). C'est la couche de plus bas niveau.

Les fonctionnalités de très bas niveau offertes par le noyau peuvent facilement planter l'ordinateur. Il faut donc une politique de restriction pour que tous les programmes ne puissent y accéder dans leur totalité. On parle de
* mode noyau
* mode utilisateur

Dans le mode utilisateur, on ne peut accéder à ces fonctionnalités qu'a travers les appels systèmes ; dans le mode noyau, on peut tout faire... Bien entendu, un appel système doit passer momentanément en mode noyau pour pouvoir exécuter les commandes pertinentes, puis il repasse automatiquement en mode utilisateur.

La définition d'un appel système pourrait donc être « fonctionnalité atomique nécessitant un passage en mode noyau ».

====Noyau, noyau monolithique, micro-noyau====

La partie principale du système d'exploitation. C'est lui qui gère les ressources, les entrées / sorties, la communication entre processus, ... Les deux architectures principales pour un noyau sont :
* noyau monolithique
* micro-noyau
La plupart des systèmes actuels sont basés sur un noyau monolithique (Linux, BSD, Mac OS X, Solaris, Windows).

Les noyaux monolithiques sont parfois décrits comme « sans vraie structure » : une grosse soupe où cohabitent toutes les fonctionnalités du système d'exploitation. L'idée d'avoir un système unique qui gère tout est effectivement peu attirante et peut poser quelques problèmes de génie logiciel...
Un noyau monolithique est donc la couche entre le matériel et les programmes utilisateurs. Pour éviter de compiler des noyaux énormes, les noyaux monolithiques actuels utilisent en plus la notion de ''module''. Ce sont des morceaux du noyau qu'on peut charger ou décharger au besoin. Si l'interface est connue, ces modules peuvent éventuellement être en binaire, ce qui permet d'utiliser des modules propriétaires avec un noyau libre.
Sous Linux, la commande
$ lsmod
permet d'obtenir la liste des modules chargés dans le noyau.

Les micro-noyaux d'un autre coté sont basés sur la remarque que seule une toute petite partie du noyau accède effectivement au matériel. Seule cette petite partie nécessite donc des privilèges et effectue des appels système. Le reste du système d'exploitation peut être programmé en mode utilisateur, « au dessus » de cette partie. Par exemple, le micro noyau offrira la possibilité de charger un nouveau processus, mais l'ordonnanceur (qui choisit quel processus devra être chargé) ne fera pas partie du micro-noyau. On parle parfois de ''services'' / ''serveurs'' au dessus du micro-noyau.
Ceci permet d'avoir un noyau bas niveau beaucoup plus petit. Bien que ceci soit une bonne idée, et que les micro-noyaux puissent fournir de meilleurs garanties de sécurité, peu de noyaux sont effectivement des micro-noyaux. Un des problèmes est qu'un tel micro-noyau est un peu plus lent que ses cousins monolithiques. La raison principale est que dans le cas d'un micro-noyau, un appel système nécessite en fait des communications inter-processus.
Andrew Tanenbaum est un fervent défenseur des micro-noyaux.

Une autre architecture possible est d'utiliser des couches successives, chacune avec des privilèges réduits. Le système Multics avait cette architecture.
Par exemple, dans le système THE (1965), les couches étaient les suivantes :
# noyau bas niveau, multiprogrammation
# allocation de la mémoire pour les processus
# IPC (communication inter processus)
# entrées / sorties (buffer, etc.)
# programmes utilisateurs (compilation, exécution, ...)
# utilisateur (Dijkstra a annoté la description de cette couche par ''« not implemented by us »'')

Une dernière catégorie de noyau est la catégorie des machines virtuelles. Ces noyaux sont un peu à part, car il s'agit d'émuler un système d'exploitation ou du matériel particulier à l'intérieur d'un autre système d'exploitation ou matériel. Le mode noyau de la machine virtuelle est en fait dans le mode utilisateur du noyau original...

==Les processus==

===Introduction===

Allez hop commençons par une petite définition du type wikipédia :

Un processus (en anglais, process), en informatique, est défini par :
* un ensemble d'instructions à exécuter (un programme) ;
* un espace mémoire pour les données de travail ;
* éventuellement, d'autres ressources, comme des descripteurs de fichiers, des ports réseau, etc.

Un ordinateur équipé d'un système d'exploitation à temps partagé est capable d'exécuter plusieurs processus de façon « quasi- simultanée ». Par analogie avec les télécommunications, on nomme multiplexage (A. Tanenbaum parle de ''multiprogrammation'') ce procédé. S'il y a plusieurs processeurs, le système essaie de répartir les processus de manière équitable sur les processeurs disponibles.

Le processus doit être imaginé comme quelque chose qui prend du temps, donc qui a un début et (parfois) une fin. De nombreux processus ne se terminent normalement jamais : système d'exploitation, serveurs web, serveurs mail, ... D'autres processus plus légers qui ne se terminent pas sont les ''daemon'' (acronyme ''a posteriori'' de "disk and execution monitor") du monde Unix.

Certains processus sont démarrés très tôt lors de la séquence de boot. Le système d'exploitation est un tel processus. Sinon, les processus sont normalement démarrés grâce à un appel système à partir d'un autre processus. L'utilisateur peut par exemple demander explicitement un nouveau processus (sous POSIX, grâce à un <tt>fork</tt> puis <tt>exec</tt>) ; mais la plupart du temps, il le fera à travers une application, par exemple en double-cliquant sur l'icône d'un programme dans l'explorateur de fichiers.

Le système d'exploitation est chargé d'allouer les ressources (mémoires, temps processeur, entrées/sorties) nécessaires aux processus et d'assurer que le fonctionnement d'un processus n'interfère pas avec celui des autres (isolation).

Pas sûr d'avoir tout compris ? Ce n'est pas grave, essayons autrement.
:'''Définition :''' un processus est un programme en train de s'exécuter.
Cette définition implique en particulier que un programme (navigateur Firefox par exemple) peut correspondre à
* zéro processus si on ne l'a pas lancé,
* un processus si on l'a lancé,
* plusieurs processus si on l'a lancé plusieurs fois.
(''Remarque :'' pour un programme comme Firefox, il y a fort à parier que l'exécution d'une seule instance de Firefox génère de multiples sous-processus...)

Que se passe-t-il quand je démarre une application?

:L'ordinateur à une nouvelle tâche à accomplir, les instructions correspondantes sont donc envoyées au processeur. Comme il a plusieurs choses à faire le choix des instructions à exécuter n'est pas forcement simple. Il faut faire en sorte de partager le processeur entre les différentes tâches de manière équitable : c'est la fameuse gestion des processus.
:Ceci permet de réaliser plusieurs activités en ~même temps~. Grâce à la gestion des processus on peut regarder un film (obtenu par des moyens tout à fait légaux cela va de soit), tout en jouant à la dame de pique.
:(et dire que certain(e)s affirment que l'homme est mono tâche)

Plusieurs processus indépendants peuvent être ''actifs'' en même temps, mais sauf si l'ordinateur possède suffisamment de processeurs, on ne peut pas les exécuter simultanément. L'impression que plusieurs programmes s'exécutent ''en même temps'' vient simplement du fait que le processeur alterne rapidement entre eux.
Comme le temps d'exécution d'une instruction par le processeur est très court, de l'ordre de la nano-seconde, le processeur peut réaliser plusieurs centaines de millions d'instructions par seconde. Ainsi, une tranche de temps de quelques fractions de seconde, partagée entre plusieurs processus, donne à l'échelle macroscopique l'illusion de la simultanéité.

'''En résumé :''' un système d'exploitation doit la plupart du temps traiter plusieurs tâches en même temps, et comme il n'a, en général, qu'un seul processeur, il devra contourner ce problème grâce à un pseudo-parallélisme. Il traite une tâche à la fois, s'interrompt et passe à la suivante. La commutation de tâches étant très rapide, il donne l'illusion d'effectuer un traitement simultané.

===La table des processus===

L'information sur les processus est conservé par le système dans une structure de données appelée ''table des processus''. Cette table contient toutes les informations nécessaires à la gestion des processus :
* état du processus
* PID
* droits
* répertoire de travail
* pointeur vers la pile
* priorités
* ...

Sous Linux, on peut accéder à ces informations à travers le système de fichiers virtuel "Procfs". Il suffit d'aller dans le répertoire <tt>/proc/</tt>.

===Création d'un processus===

Pour les système POSIX, la création d'un processus est très simple : on utilise la fonction <tt>fork()</tt>. En C, le prototype de la fonction se trouve dans le fichier d'entêtes <tt>unistd.h</tt>.

Cette fonction prend 0 argument et permet de faire la chose suivante : elle crée un nouveau processus qui est une copie conforme du processus appelant. La seule différence visible entre l'ancien et le nouveau processus est que les processus ont un numéro (PID) différent. Pour le processus appelant, il peut obtenir le PID du nouveau processus en regardant la valeur de retour de <tt>fork</tt>. Pour le nouveau processus, cette valeur vaudra 0, et il devra utiliser la fonction <tt>getpid()</tt> pour obtenir son numéro.

Le processus appelant est appelé le ''père'' alors que le nouveau processus est appelé le ''fils''.

Notez que l'espace mémoire du processus est dupliqué plutôt que partagé. Ceci veut dire que les processus ne peuvent pas communiquer en utilisant leur variables... Par contre, les descripteurs de fichiers du fils sont hérités directement de ceux du père ; ils peuvent donc essayer de communiquer en passant par ces fichiers. (Mais cela pose de nombreux problèmes de synchronisation.)

Voici par exemple un petit programme C qui lance un processus fils:
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {

int pid ;
int pid_fils ;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
} else {
printf(" >> Je suis le fils.\n");
}

return(0);

}
Après compilation, voici un exemple d'exécution du programme résultant :
$ ./pere_fils
> Le processus 8248 démarre...
>> Je suis le fils.
>> Je suis le père (pid du fils = 8249).

Voici un autre exemple d'exécution :
$ ./pere_fils
> Le processus 8269 démarre...
>> Je suis le père (pid du fils = 8270).
>> Je suis le fils.

Notez que les numéros sont différents, et que l'ordre d'affichage n'est pas le même. Cela vient de l'ordonnancement des deux processus qui peut différer.

La technique consistant à faire
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
...
}
montre que malgré le fait que les processus soient identiques à l'origine, on peut faire beaucoup de chose.

:'''Remarque :''' <tt>fork()</tt> n'est pas directement un appel système, mais une fonction qui utilise l'appel système <tt>clone()</tt>. Cet appel système ne fait pas partie de la norme POSIX...

La deuxième technique utilisée dans les systèmes POSIX consiste à utiliser <tt>fork()</tt> pour dupliquer le processus, puis à complètement remplacer le fils par un nouveau processus. La fonction correspondante est la fonction <tt>execv</tt> :
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
execv("/usr/bin/...", argv);
...
}
La fonction <tt>execv</tt> prend 2 arguments : une chaîne contenant le chemin d'accès à un programme, et un tableau d'arguments à donner au programme. (C'est un peu plus compliqué que ça : le premier élément du tableau est le nom du programme, et le tableau doit se terminer par un pointeur NULL.)

Une dernière fonction importante est la fonction <tt>wait(pid)</tt> qui permet à un processus d'attendre l'arrêt du processus <tt>pid</tt>.

-- ...

L'API WIN32 possède de nombreuses fonctions avec des fonctionnalités similaires. Par exemple, la fonction [http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx <tt>CreateProcess</tt>] permet de créer un nouveau processus (comme un <tt>fork</tt> suivi d'un <tt>exec</tt>), mais elle nécessite ... 10 arguments !

----

Un autre moyen de créer des processus est d'utiliser des 'processus légers' appelés Thread. Ces processus légers partage seulement une partie de la mémoire, ce qui en pratique est plus rapide pour simuler un parallélisme. On passe alors par une autre fonction. Sous GNU/Linux, lors de l'écriture d'un programme écrit en C il faut utiliser la bibliothèque pthread.h et lors de la compilation, faire un lien vers celle ci, en utilisant le paramètre -lpthread.

====Arborescence des processus dans les systèmes POSIX====

Nous avons vu que la fonction <tt>fork()</tt> permet de créer un processus fils. Le père connaît le PID de son fils : il lui est donné par la fonction <tt>fork()</tt>. Comme le fils peut lui même créer des processus fils, on obtient rapidement une arborescence de processus.

Vous pouvez visualiser cette arborescence à partir d'un terminal avec la commande <tt>pstree</tt> (l'option <tt>-p</tt> permet de demander l'affichage des PID)
$ pstree -p
init(1)─┬─acpid(25425)
├─atd(14365)
├─console-kit-dae(3632)─┬─{console-kit-dae}(3633)
│ ├─{console-kit-dae}(3641)
...
├─cron(14315)
├─dbus-daemon(15590)
├─dbus-daemon(3511)
...
├─getty(4095)
├─getty(4096)
├─getty(4097)
├─getty(4098)
├─getty(4099)
├─gpm(3528)
...
├─kded4(15769)
├─kdeinit4(15766)───klauncher(15767)
├─kdm(15564)─┬─Xorg(15566)
│ └─kdm(15573)───sh(15608)─┬─conky(15751)
│ ├─fluxbox(15703)───firefox-bin(6063)─┬─{firefox-bin}(6064)
│ │ ├─{firefox-bin}(6065)
...
│ ├─ssh-agent(15698)
│ ├─unclutter(15742)
│ ├─wicd-client(15749)
│ └─xscreensaver(15683)
...
├─rsyslogd(6850)─┬─{rsyslogd}(6140)
│ └─{rsyslogd}(6141)
├─screen(4427)─┬─bash(4428)───pstree(9307)
│ ├─bash(4429)───man(7952)───pager(7965)
│ ├─bash(4430)───vi(30568)
│ ├─bash(18395)───vi(28512)
│ └─mutt(8763)
...

Le processus <tt>init</tt> est l'ancêtre de tout les processus, il a toujours 1 comme PID.

'''Remarque :''' sous Windows, les processus ne sont pas organisé en arborescence...

====Mort d'un processus dans un système POSIX====

Un processus peut se terminer pour plusieurs raisons :
* volontairement, grâce à la fonction <tt>exit()</tt> (POSIX) ou <tt>ExitProcess()</tt> (Windows),
* à cause d'une erreur,
* en recevant un signal d'un autre processus, grâce à la fonction <tt>kill()</tt> (POSIX) ou <tt>TerminateProcess()</tt> (Windows).

Lorsqu'un processus se termine, plusieurs choix sont possibles :
* que fait-on de ses fils ?
* que fait-on de son père ?

Linux fait la chose suivante : quand un processus s'arrête,
* tous ces fils s'arrêtent,
* son père reçoit un signal le prévenant que son fils vient de mourir.

Pour que le père puisse recevoir le signal correspondant, il faut qu'il utilise la fonction <tt>wait()</tt> ou <tt>waitpid()</tt>. Tant que le parent existe et qu'il n'a pas reçu le signal disant qu'un de ces fils est mort, le processus fils n'est pas entièrement supprimé : il devient un ''zombie''. (Il n'occupe plus vraiment de place en mémoire, mais le système garde juste suffisamment d'information pour pouvoir prévenir le père si celui ci demande l'état du fils.)

'''Remarque :''' les processus Windows ne sont pas organisés sous forme d'arborescence. Chaque processus peut surveiller l'état d'un autre processus, s'il connaît son PID. Il n'y a donc pas de notion de processus ''zombie'' sous Windows.

Voici un petit programme C qui crée un processus fils, ne fait rien pendant 20 secondes, puis demande l'état de son fils :
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
int pid ;
int pid_fils ;
int w;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
printf(" >> Je suis le père et j'attends un peu.\n");
sleep(20);
printf(" >> Je suis le père et je demande l'état de mon fils.\n");
wait(&w);
printf(" >> Mon fils est mort (signal %i).\n", w);
while(1) sleep(1);
} else {
printf(" >> Je suis le fils.\n");
while (1) sleep(1);
exit(0);
}
return(0);
}
Si on tue le processus fils pendant que le père ne fait rien, le processus fils devient un zombie. Dès que le père fait le <tt>wait</tt>, il reçoit la valeur du signal qui a terminé le processus et le zombie disparaît.

Si on ne tue pas le processus fils, le père n'exécutera jamais le <tt>printf(" >> Mon fils est mort...);</tt>.

'''Remarque :''' dans un système POSIX, lorsqu'un processus meurt, ses fils deviennent ''orphelins''. Il continuent leur exécution mais sont adopté par <tt>init</tt> (PID : 1). Dans certains cas lorsque le processus est arrêté, il envoie explicitement un signal <tt>SIGTERM</tt> pour tuer ses processus fils. C'est par exemple ce qui arrive lorsqu'on lance des application à partir d'un terminal et que l'on quitte le terminal en question...

===États d'un processus===

On peut imaginer un SE dans lequel les processus pourraient être dans trois états :
* en cours d'exécution,
*bloqué : il attend un événement extérieur pour pouvoir continuer (par exemple une ressource; lorsque la ressource est disponible, il passe à l'état "prêt")
*prêt : suspendu provisoirement pour permettre l'exécution d'un autre processus.

Dans un système avec un unique processeur, au plus un processus peut se trouver dans l'état ''en cours d'exécution''. Par contre, il peut y avoir de nombreux processus dans l'état ''bloqué'' ou dans l'état ''prêt''.

Un processus peut passer d'un état à l'autre :
# de ''en exécution'' à ''bloqué'' lorsqu'une ressource n'est pas disponible (entrées / sortie par exemple),
# de ''bloqué'' à ''prêt'' si la ressource ayant provoqué le blocage devient disponible,
# de ''en exécution'' à ''prêt'' si le système décide de suspendre l'exécution du processus,
# de ''prêt'' à ''en exécution'' si le système décide de lancer l'exécution du processus.

On peut résumer ceci par le graphe de transitions suivant :

[[Image:Diagrammedétatdunprocessus.png]]

Les transition manquantes ne sont pas possible directement mais doivent passer par des transition intermédiaires.

On peut ajouter 2 états :
* ''nouveau'' pour un processus qui vient d'être créé,
* ''terminé'' pour un processus qui vient de se terminé.

Dans les systèmes type ''ordinateur de bureau'', le passage de ''nouveau'' à ''prêt'' est automatique mais dans des systèmes temps réel, un processus peut parfois attendre dans cet état.

L'état ''terminé'' est en général passager. Par exemple, lorsqu'un processus terminé est un zombie, le processus n'est conservé que dans la table des processus. La mémoire utilisé par le processus est libérée. La question de savoir si ceci est véritablement un état du processus est donc essentiellement une question de vocabulaire.

:exercice : ajouter les états ''nouveau'' et ''terminé'' et les transitions correspondantes au graphe précédent. Identifiez des situations provoquant les transitions possibles entre états.

===Ordonnancement des processus===

Nous avons vu qu'il pouvait y avoir de nombreux processus dans la table de processus (environ 150 sur mon ordinateur en ce moment même). Parmi ces processus, un seul (sur une machine à un processeur) peut se trouver dans l'état ''en exécution''. C'est au système d'exploitation de décider qui, à un moment donnée, doit se trouver dans cet état. La partie du système faisant ceci s'appelle ''ordonnanceur'' (ou ''scheduler'' en anglais).
En utilisant le contenu de la table des processus et éventuellement d'autres information, ordonnanceur doit donc gérer les transition entre états de tous les processus, et envoyer l'information nécessaire aux composants adéquat du noyau.

Comme d'habitude, l'ordonnanceur doit faire des compromis entre :
* la vitesse,
* l'utilisation de la mémoire,
* l'optimalité de la solution proposée.

'''Remarque : ''' l'ordonnanceur est lui même un processus (ou un morceau de processus dans le cas des noyaux monolithiques).

====Ordonnancement non préemptif====

'''FIFO.'''
L'algorithme d'ordonnancement le plus facile est probablement celui de type ''FIFO'' : premier arrivé, premier servi. Autrement dit, on préempte premier processus arrivé, et on l'exécute jusqu'à la fin. La seul structure de donnée est donc simplement une ''file''.

'''Plus court temps d'exécution.'''
Dans certain cas, on peut prévoir a l'avance le temps processeur dont aura besoin un processus pour s'exécuter. On peut alors choisir le processus le plus court et l'exécuter en premier. Ceci a en général tendance à diminuer le temps d'attente moyen d'un processus ; mais si des processus courts sont crées régulièrement, on peut assister à une ''famine'' : un processus peut ne jamais s'exécuter.

:exercice : trouver une suite de processus qui provoque une famine.

Ces deux exemples sont acceptables pour un ''traitement par lots'' (batch) par exemple pour des calculs numériques. Ils ne sont par contre pas du tout adaptés pour un ordinateur personnel ou un système temps réels. (Pas de ''multiprogrammation''.)

====Ordonnancement préemptif====

Pour pouvoir donner l'illusion de simultanéité, les processus sont en général exécutés par tranches de temps spécifiées à l'avance (''time slice'' en anglais). Au bout de ce temps, le noyau reçoit une interruption et examine les processus. Il peut décider de continuer le processus courant, ou bien le remplacer par un autre processus. on parle de préemption.

Windows 3.1 ou MacOS 9 étaient des systèmes ''collaboratifs'' car les processus devaient explicitement laisser la main aux autres processus. Tous les systèmes d'exploitation modernes sont maintenant préemptifs. On parle maintenant de système préemptif lorsque la préemption peut s'effectuer même sur des processus en mode noyau.
On parle parfois de noyau préemptible lorsque que les opérations en mode noyau sont elle même préemptibles.

'''Tourniquet.'''
L'algorithme le plus simple est probablement celui du tourniquet (''round Robin'' en anglais). C'est une variante de l'algorithme FIFO vu plus haut, mais qui préempte le processus courant au bout d'un moment. Si ce processus est encore en exécution, on le remet à la fin de la file des processus.

Le temps imparti à chaque processus ne doit pas être trop court (sinon, le changement de contexte prend trop de temps par rapport à l'exécution des processus) ni trop long (sinon, on perd l'illusion de parallélisme, et un processus bloqué risque d'occuper le processeur pendant trop longtemps).

Voici ce qu'on peut trouver dans le livre "Understanding the Linux kernel" :

<cite>
The choice of quantum duration is always a compromise. The rule of thumb adopted by Linux is: choose a duration as long as possible, while keeping good system response time.
</cite>

(extrait du chapitre [http://oreilly.com/catalog/linuxkernel/chapter/ch10.html "Process Scheduling"]).

'''Tourniquet avec priorité.'''
Tous les processus ne naissent pas égaux : certains ont une importance plus élevée (les processus systèmes par exemple). Dans un cas comme le précédent, tous les processus ont le même statut...
Pour corriger ce problème, on utilise parfois un algorithme similaire, mais on choisit le premier processus de priorité la plus élevé possible. Plutôt que de parcourir la file à sa rechercher, on utilise en fait plusieurs files : une pour chaque priorité.

Il faut faire attention car les processus de priorité basse risquent de ne jamais être exécutés (famine)... Par exemple, on peut diminuer petit à petit la priorité des processus qu'on exécute...

Une autre solution pour gérer les priorité en évitant certaines famines est d'exécuter toutes les files, mais pas en proportion égale. Par exemple, on choisit un processus dans les piles de priorité 1, 2, 1, 3, 1, 2, 1, 4, 1, 2, 1, 3, 1, 2, 1, ... De cette manière, les processus de la première file sont exécutés 2 fois plus de fois que ceux de la file 2, et 4 fois plus de fois que ceux de la file 3.

:exercice : donnez un algorithme pour générer la suite précédente pour un nombre donné de files. Il faut que la file ''i'' soit utilisée 2 fois plus souvent que la pile ''i+1''.

'''Répartition garantie.'''
Chaque tache reçoit la même proportion du processeur, et chaque utilisateur reçoit la même proportion également.

'''tirage aléatoire.'''
À chaque étape, on tire un "billet" au hasard, et le processus qui a le "billet gagnant" s'exécute.

Principe de priorité : Les processus qui ont été définit comme prioritaire on plus de "billet" à leur nom et ont donc plus de chance d'être tiré.

''NB : POSIX définit une commande "nice" qui permet e donner à un processus un priorité plus faible (et par conséquent, nice -x augmente cette priorité). Il est évident que tout le monde ne doit pas pouvoir utiliser cette commande, il vaut mieux que l'administrateur se réserve ce droit''

'''Ordonnancement équitable.'''

==La mémoire==

===Introduction===

RAM = Random Acces Memory. C'est ce que l'on appelle couramment la mémoire vive, elle peut être modifié à l'infini et sert à stocker temporairement les fichiers que l'ordinateur exécute.

ROM = Read Only Memory. On l'appelle aussi mémoire fixe ou mémoire morte, dès que l'on enregistre, le contenu d'une mémoire ROM ne peut pas être modifié (ex: un CD-ROM).

'''Gestion de la mémoire : '''

Lors du boot du PC, le système est chargé en mémoire.
Tout processus créé est aussi chargé dans la mémoire.

Lorsque l'on créé uns seul processus, il est plus pratique de le charger en "bas" de la mémoire, à partir de la première case de l'espace mémoire. Puis les nouveaux processus peuvent être charger par dessus. Ainsi la machine comprend où commence l'espace mémoire.

Problèmes :
1 - l'espace d'adressage ne commence pas à 0;
2 - un processus peut demander dynamiquement de la mémoire;
3 - avec un accès direct, un processus peut faire "planter" un autre.

==> Il faut avoir une couche d'abstraction au-dessus de la mémoire physique.

===Espaces d'adressage===

Et si l'on créait des espaces d'adressage distincts pour chaque processus ?
Par exemple : chaque processus utilise des adresse de 0 à n de la mémoire, on converti alors ces adresses en adresses physiques.

Certains des premiers processeurs avaient deux registres supérieurs :

- une Base => adresse physique du début de l'espace d'adressage

- une Limite => adresse physique de fin de l'espace d'adressage

Par exemple, lors de l'exécution d'un processus l'accès à une case "a" se transforme en l'accès à la Base+a et un test pour vérifier que : a+Base < Limite.

Malgré tout, ceci ne résout pas les problèmes liés au fait que des processus sont créés et disparaissent, réclament ou libèrent de la mémoire.

===Va-et-vient (swapping)===

====Idée====

Et si pour gérer tout cela on utilisait une mémoire auxiliaire (disque), pour stocker l'état de la mémoire de processus.

La mémoire vue par les processus ne correspond pas à la mémoire physique. À un instant donné, certains processus peuvent se retrouver sur le disque (dans le SWAP).

Quand un processus apparait, on lui cherche un morceau d'espace libre dans la mémoire.

====gestion de la mémoire====

* tableau de bits
* liste chaînée

====Allocation====

* first fit
* next fit
* best fit
* worst fit

===Mémoire virtuelle===

====Idée====

====Pagination====

====Traduction des adresses====

====Table des pages====

====Table inversée====

====Remplacement des pages====

==Les entrées / sorties==

----
----

==Références==

* le livre « Systèmes d'exploitation » de Andrew Tanenbaum est disponible à la BU
* la page du [http://sos.enix.org/fr/PagePrincipale projet SOS]
* la [http://www.opengroup.org/onlinepubs/009695399/nfindex.html norme POSIX:2004]
* l'[http://msdn.microsoft.com/en-us/library/aa383749(VS.85).aspx API win32]
* [http://www.lemis.com/grog/Documentation/Lions/index.php Commentary on the Sixth Edition UNIX Operating System]

INFO502 : Systèmes d'exploitation

2009-12-03T17:46:52Z

Hatat : /* TP */ Ajout du TP2

Ce wiki est un complément de cours pour le cours « info-502 : systèmes d'exploitation ». La participation au wiki est fortement encouragée.

Pour pouvoir modifier les pages, inscrivez-vous (lien en haut à droite) pour obtenir un login et mot de passe. (Choisissez un login du style ''PrenomNom''...)

Je vous conseille d'aller lire [http://meta.wikimedia.org/wiki/Aide:Contenu ce guide] pour vous familiariser avec les wikis.

Exercice : si vous n'en avez pas, créez-vous un compte et essayez de modifier cette page (correction de fautes d'hortographe, rajout de détails, mise en page, ...)

Vous pouvez aussi utiliser la page de discussion pour ... discuter. (Ou poser des questions, faire des commentaires etc.)

----
----
==Auteur du cours==

===Nouvelles===

===Supports===

====TD====

Sujets de TD :
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td1.pdf Ordonnancement],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td2.pdf Gestion de la mémoire],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td3.pdf Systèmes de fichiers].

====TP====

# Découverte de SOS :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp1.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp1.tar.gz code source].
# Gestion de la mémoire du noyau :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp2.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp2.tar.gz code source].

==Introduction==

-- ...

==Repères historiques==

Voici quelques évènements clés dans l'histoire des systèmes d'exploitation. Pour plus de détails, ou pour des compléments sur l'histoire de l'informatique, je vous renvoie sur Wikipedia : [http://en.wikipedia.org/wiki/History_of_operating_systems "History of operating systems"] et [http://en.wikipedia.org/wiki/History_of_computing "History of computing"].

Les premiers ordinateurs ne comportaient pas vraiment de système d'exploitation : c'étaient des opérateurs humains qui géraient tout. (C'était juste après la seconde guerre mondiale, l faut savoir que les langages de programmation n'existaient même pas...) La petite histoire (??) raconte qu'à un moment, les processus pour l'ordinateur de l'université de Cambridge étaient accrochés sur une corde à linge et que c'était la couleur des pinces à linges qui donnait la priorité. (??)

Le passage à la notion de système d'exploitation c'est faite graduellement pour répondre à la complexité de plus en plus grande des ordinateurs et aux demandes des utilisateurs.

Les premier systèmes d'exploitation datent probablement de 1956. Ils permettaient simplement d'exécuter un nouveau programme lorsque le précédent était terminé. Les ordinateurs d'IBM de la famille System/360 ont ensuite eu toute une série de systèmes d'exploitation plus ou moins similaires : OS/360, DOS/360 (rien à voir avec MS-DOS), TSS/360... C'est à cette époque qu'est apparu la notion de multiprogrammation (possibilité d'avoir plusieurs processus entrelacés.)
C'est également au début des années 60 qu'on a commencé à voir des systèmes avec temps partagé : plusieurs utilisateurs pouvaient utiliser un ordinateur. Le système Multics a été, à ce niveau comme à d'autres, assez révolutionnaire. Multics a été utilisé jusqu'en 2000 !

Multics n'était par contre pas approprié pour les mini-ordinateurs où le nombre d'utilisateur est relativement restreint. En 1969, Ken Thomson
a développé une variante simplifié de Multix : Unix...

Ce n'est qu'un peu plus tard (1979) que la première version de DOS (86-DOS ou QDOS) apparaît. 86-DOS sera racheté par Microsoft un 1980...

'''Liens et compléments :'''
* [http://en.wikipedia.org/wiki/Timeline_of_operating_systems Timeline of operating systems]
* généalogie des systèmes Unix : [http://www.levenez.com/unix/ Unix History]
* généalogie de Windows : [http://www.levenez.com/windows/ Windows History]
* généalogie des systèmes non-Unix : [http://www.oshistory.net/metadot/index.pl?id=2165 timeline of non-Unix operating systems]

==Vue d'ensemble==

Ce cours reste assez généraliste et essaie de regarder les principales fonction d'un système d'exploitation. Les systèmes de type Unix (Linux) sera un exemple privilégié. À cause de leur complexité intrinsèque, les évolutions modernes (architectures multicoeur ou multiprocesseur, ...) seront en partie ignorée dans un premier temps.

Les problèmes fins de communication entres processus ne seront que très peu abordés, car ils font l'objet d'un cours séparé (info604) pour la filière info.

Nous allons suivre l'ordre classique consistant à regarder :
# les processus
# la mémoire
# les entrées / sorties

La fin du cours dépendra du temps restant...

===Les processus===

Un processus est simplement un programme « en exécution ». À tout instant, un ordinateur de bureau contemporain contient de nombreux processus qui doivent partager le (les) processeur(s) pour donner l'impression qu'ils s'exécutent « en même temps ». Un des rôles du système d'exploitation consiste à décider dans quel ordre les processus vont effectivement pouvoir utiliser le processus.

===La mémoire===

La mémoire est, comme le processeur, une ressource partagée par les différents processus. Il faut donc gérer la quantité de mémoire allouée et utilisée pour que les processus n'aient pas à s'occuper de ceci. Un des concepts fondamentaux est celui de mémoire virtuelle. Ceci permet d'offrir un espace mémoire pour chacun des processus de manière transparente.

===Les entrées / sorties===

Un ordinateur n'est pas (plus) un système indépendant du reste du monde : il interagit avec l'extérieur à travers des périphériques d'entrées/sorties (clavier / écran / souris / ...). La gestion de ces périphériques pose un ensemble de problèmes que nous aborderons brièvement...

===...===

Une fois ces notions vues, nous regarderons peut-être les problèmes de sécurité, de multimédia ou des architectures multiprocesseurs.

==Préliminaires==

===Quoi ?===

Les ordinateurs, ou plus simplement les micro contrôleurs sont des circuits électroniques avec une puce « processeur ». Le développement d'applications n'est pas facile si on se place au niveau électronique et que l'on parle directement au CPU. Pour faciliter la vie des programmeurs, plusieurs couches d'abstraction sont nécessaires. La première se place au niveau matériel et s'occupe directement des problèmes électroniques ou de très bas niveau. Il s'agit du ''firmware''. Il répond par exemple aux questions comme :
* qu'elle est l'amplitude des signaux envoyés par l'horloge ?
* est-ce que l'UC possède un pipeline ?
* ...
Un firmware est donc forcement très lié au matériel sur lequel il tourne.

La couche suivante est le système d'exploitation à proprement parler. Dans le cas que vous connaissez le mieux (ordinateur personnel), le système d'exploitation fournit une interface pour :
* exécuter un programme
* exécuter plusieurs programmes « en même temps »
* gérer les ressources (temps processeur, mémoire disponible, entrées / sorties)
* les opérations sur les fichiers
* offrir des garanties de sécurité

===Où ?===

On trouve des systèmes d'exploitation partout :

* dans les ordinateurs personnels (Linux, BSD, MacOS, Solaris, Windows, ChromeOS (?))
* dans les PDA (PalmOS, ...)
* dans les téléphones portables (Android, OpenMoko,Symbian,)
* console de jeux
* lecteur MP3 (Rockbox, ...)
* les microcontroleurs « avancés »

===Comment ?===

====Langage de programmation====

Le système d'exploitation se situe entre le firmware (très bas niveau) et l'utilisateur. La nécessité d'accéder à ces ressources de très bas niveau implique que les langages de haut niveaux (Java, Ada, Python, ...) ne sont pas du tout adaptés à l'écriture des systèmes d'exploitation.
Le langage le plus utilisé reste à ce jours le langage C : Linux, BSD, MacOS, Windows, ... sont tous écrits pour leur plus grande partie en C.

Vous avez normalement un cours de C en parallèle, et les TPs utiliseront le langage C. (La référence sur le langage C reste à mon goût le livre de Kernighan et Ritchie : « the C Programming language ». (Disponible en francais à la BU sous le titre « Le langage C : norme Ansi ».) Il existe de nombreux autres livres / documents sur la programmation C comme le [http://www-clips.imag.fr/commun/bernard.cassagne/Introduction_ANSI_C.html polycopié de Bernard Cassagne « introduction au langage C »].

Les premiers systèmes d'exploitation étaient écrits directement en langage machine, ou bien en langage d'assembleur ; et les systèmes actuels comportent encore quelques parties de très bas niveau en langage d'assemblage...

====Notion d'appel système, norme POSIX====

La programmation de haut niveau en C est assez différente de la programmation système. De nombreuses fonctions C utilisent en fait des « appels système », c'est à dire des appels de fonctionnalités propres du système d'exploitation. Les appels système typiques sont :
* les fonctions relatives aux fichiers (création, suppression, modification...)
* les fonctions relatives à la gestion de la mémoire
* les fonctions relatives aux processus (<tt>fork</tt>)
* ...

De nombreux système d'exploitation proposent une interface [http://en.wikipedia.org/wiki/Posix POSIX] (« '''P'''ortable '''O'''perating '''S'''ystem '''I'''nterface for Uni'''x''' »). Cette norme définit entre autres un ensemble de fonctions pour utiliser les appels systèmes.
Le nombre de ces fonctions est relativement faible : une centaine ; et chacune correspond en gros à un appel système. Certaines de ces fonctions ne sont pas définies directement dans le système d'exploitation, mais dans des librairies. Pour Linux, il s'agit en général de la librairie Glibc (GNU C Library).

Par exemple, la fonction <tt>open</tt> (qui permet d'ouvrir un fichier) correspond exactement à un appel système ; alors que la fonction <tt>malloc</tt> (qui permet d'allouer dynamiquement de la mémoire dans le tas) peut générer plusieurs appels système (<tt>brk</tt> et <tt>sbrk</tt>).

Pour visualiser les appels systèmes effectués par un programme sous Linux, vous pouvez utilisez l'utilitaire <tt>strace</tt> ou <tt>ltrace</tt>. Par exemple, dans le shell :
$ strace -e trace=file ls -l 2> trace
permet de récupérer tous les appels systèmes relatifs aux fichiers lors de l'appel à <tt>ls -l</tt>. La liste des appels système est redirigée dans le fichier <tt>trace</tt> qui contiendra par exemple des lignes telles que
lstat64("Desktop", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lgetxattr("Desktop", "security.selinux", 0x8cc08e0, 255) = -1 ENODATA (No data available)
dénotant ainsi un appel aux appels système <tt>lstat64</tt> et <tt>lgetxattr</tt>...

Les principaux systèmes compatibles POSIX sont :
* Linux
* BSD (et variantes)
* Mac OS X
* Solaris

De nombreux appels systèmes sont disponibles directement (sans avoir besoin d'écrire un programme C) à travers le shell. Exécuté dans un terminal, le shell permet, en première approximation, de passer directement des commandes au système d'exploitation. (La norme POSIX définit également un ensemble de fonctions du shell. Il est donc relativement aisé de changer de système d'exploitation tant qu'on reste dans les systèmes compatibles POSIX.)

Windows d'un autre côté utilise l'interface Win32 API, qui définit plusieurs milliers de fonctions. La plupart de ces fonctions peuvent utiliser plusieurs appels système...

Les systèmes d'exploitation qui utilisent l'API Win32 sont :
* Windows, depuis Windows95.

Il est possible d'installer un environnement compatible POSIX sur une machine Windows grâce à Cygwin. (C'est d'ailleurs fortement conseillé si vous ne voulez pas installer une version de Linux ou BSD sur votre ordinateur personnel...)

====Mode noyau / mode utilisateur====

La partie fondamentale du système d'exploitation est le ''noyau'' (''kernel'' en anglais). C'est la couche de plus bas niveau.

Les fonctionnalités de très bas niveau offertes par le noyau peuvent facilement planter l'ordinateur. Il faut donc une politique de restriction pour que tous les programmes ne puissent y accéder dans leur totalité. On parle de
* mode noyau
* mode utilisateur

Dans le mode utilisateur, on ne peut accéder à ces fonctionnalités qu'a travers les appels systèmes ; dans le mode noyau, on peut tout faire... Bien entendu, un appel système doit passer momentanément en mode noyau pour pouvoir exécuter les commandes pertinentes, puis il repasse automatiquement en mode utilisateur.

La définition d'un appel système pourrait donc être « fonctionnalité atomique nécessitant un passage en mode noyau ».

====Noyau, noyau monolithique, micro-noyau====

La partie principale du système d'exploitation. C'est lui qui gère les ressources, les entrées / sorties, la communication entre processus, ... Les deux architectures principales pour un noyau sont :
* noyau monolithique
* micro-noyau
La plupart des systèmes actuels sont basés sur un noyau monolithique (Linux, BSD, Mac OS X, Solaris, Windows).

Les noyaux monolithiques sont parfois décrits comme « sans vraie structure » : une grosse soupe où cohabitent toutes les fonctionnalités du système d'exploitation. L'idée d'avoir un système unique qui gère tout est effectivement peu attirante et peut poser quelques problèmes de génie logiciel...
Un noyau monolithique est donc la couche entre le matériel et les programmes utilisateurs. Pour éviter de compiler des noyaux énormes, les noyaux monolithiques actuels utilisent en plus la notion de ''module''. Ce sont des morceaux du noyau qu'on peut charger ou décharger au besoin. Si l'interface est connue, ces modules peuvent éventuellement être en binaire, ce qui permet d'utiliser des modules propriétaires avec un noyau libre.
Sous Linux, la commande
$ lsmod
permet d'obtenir la liste des modules chargés dans le noyau.

Les micro-noyaux d'un autre coté sont basés sur la remarque que seule une toute petite partie du noyau accède effectivement au matériel. Seule cette petite partie nécessite donc des privilèges et effectue des appels système. Le reste du système d'exploitation peut être programmé en mode utilisateur, « au dessus » de cette partie. Par exemple, le micro noyau offrira la possibilité de charger un nouveau processus, mais l'ordonnanceur (qui choisit quel processus devra être chargé) ne fera pas partie du micro-noyau. On parle parfois de ''services'' / ''serveurs'' au dessus du micro-noyau.
Ceci permet d'avoir un noyau bas niveau beaucoup plus petit. Bien que ceci soit une bonne idée, et que les micro-noyaux puissent fournir de meilleurs garanties de sécurité, peu de noyaux sont effectivement des micro-noyaux. Un des problèmes est qu'un tel micro-noyau est un peu plus lent que ses cousins monolithiques. La raison principale est que dans le cas d'un micro-noyau, un appel système nécessite en fait des communications inter-processus.
Andrew Tanenbaum est un fervent défenseur des micro-noyaux.

Une autre architecture possible est d'utiliser des couches successives, chacune avec des privilèges réduits. Le système Multics avait cette architecture.
Par exemple, dans le système THE (1965), les couches étaient les suivantes :
# noyau bas niveau, multiprogrammation
# allocation de la mémoire pour les processus
# IPC (communication inter processus)
# entrées / sorties (buffer, etc.)
# programmes utilisateurs (compilation, exécution, ...)
# utilisateur (Dijkstra a annoté la description de cette couche par ''« not implemented by us »'')

Une dernière catégorie de noyau est la catégorie des machines virtuelles. Ces noyaux sont un peu à part, car il s'agit d'émuler un système d'exploitation ou du matériel particulier à l'intérieur d'un autre système d'exploitation ou matériel. Le mode noyau de la machine virtuelle est en fait dans le mode utilisateur du noyau original...

==Les processus==

===Introduction===

Allez hop commençons par une petite définition du type wikipédia :

Un processus (en anglais, process), en informatique, est défini par :
* un ensemble d'instructions à exécuter (un programme) ;
* un espace mémoire pour les données de travail ;
* éventuellement, d'autres ressources, comme des descripteurs de fichiers, des ports réseau, etc.

Un ordinateur équipé d'un système d'exploitation à temps partagé est capable d'exécuter plusieurs processus de façon « quasi- simultanée ». Par analogie avec les télécommunications, on nomme multiplexage (A. Tanenbaum parle de ''multiprogrammation'') ce procédé. S'il y a plusieurs processeurs, le système essaie de répartir les processus de manière équitable sur les processeurs disponibles.

Le processus doit être imaginé comme quelque chose qui prend du temps, donc qui a un début et (parfois) une fin. De nombreux processus ne se terminent normalement jamais : système d'exploitation, serveurs web, serveurs mail, ... D'autres processus plus légers qui ne se terminent pas sont les ''daemon'' (acronyme ''a posteriori'' de "disk and execution monitor") du monde Unix.

Certains processus sont démarrés très tôt lors de la séquence de boot. Le système d'exploitation est un tel processus. Sinon, les processus sont normalement démarrés grâce à un appel système à partir d'un autre processus. L'utilisateur peut par exemple demander explicitement un nouveau processus (sous POSIX, grâce à un <tt>fork</tt> puis <tt>exec</tt>) ; mais la plupart du temps, il le fera à travers une application, par exemple en double-cliquant sur l'icône d'un programme dans l'explorateur de fichiers.

Le système d'exploitation est chargé d'allouer les ressources (mémoires, temps processeur, entrées/sorties) nécessaires aux processus et d'assurer que le fonctionnement d'un processus n'interfère pas avec celui des autres (isolation).

Pas sûr d'avoir tout compris ? Ce n'est pas grave, essayons autrement.
:'''Définition :''' un processus est un programme en train de s'exécuter.
Cette définition implique en particulier que un programme (navigateur Firefox par exemple) peut correspondre à
* zéro processus si on ne l'a pas lancé,
* un processus si on l'a lancé,
* plusieurs processus si on l'a lancé plusieurs fois.
(''Remarque :'' pour un programme comme Firefox, il y a fort à parier que l'exécution d'une seule instance de Firefox génère de multiples sous-processus...)

Que se passe-t-il quand je démarre une application?

:L'ordinateur à une nouvelle tâche à accomplir, les instructions correspondantes sont donc envoyées au processeur. Comme il a plusieurs choses à faire le choix des instructions à exécuter n'est pas forcement simple. Il faut faire en sorte de partager le processeur entre les différentes tâches de manière équitable : c'est la fameuse gestion des processus.
:Ceci permet de réaliser plusieurs activités en ~même temps~. Grâce à la gestion des processus on peut regarder un film (obtenu par des moyens tout à fait légaux cela va de soit), tout en jouant à la dame de pique.
:(et dire que certain(e)s affirment que l'homme est mono tâche)

Plusieurs processus indépendants peuvent être ''actifs'' en même temps, mais sauf si l'ordinateur possède suffisamment de processeurs, on ne peut pas les exécuter simultanément. L'impression que plusieurs programmes s'exécutent ''en même temps'' vient simplement du fait que le processeur alterne rapidement entre eux.
Comme le temps d'exécution d'une instruction par le processeur est très court, de l'ordre de la nano-seconde, le processeur peut réaliser plusieurs centaines de millions d'instructions par seconde. Ainsi, une tranche de temps de quelques fractions de seconde, partagée entre plusieurs processus, donne à l'échelle macroscopique l'illusion de la simultanéité.

'''En résumé :''' un système d'exploitation doit la plupart du temps traiter plusieurs tâches en même temps, et comme il n'a, en général, qu'un seul processeur, il devra contourner ce problème grâce à un pseudo-parallélisme. Il traite une tâche à la fois, s'interrompt et passe à la suivante. La commutation de tâches étant très rapide, il donne l'illusion d'effectuer un traitement simultané.

===La table des processus===

L'information sur les processus est conservé par le système dans une structure de données appelée ''table des processus''. Cette table contient toutes les informations nécessaires à la gestion des processus :
* état du processus
* PID
* droits
* répertoire de travail
* pointeur vers la pile
* priorités
* ...

Sous Linux, on peut accéder à ces informations à travers le système de fichiers virtuel "Procfs". Il suffit d'aller dans le répertoire <tt>/proc/</tt>.

===Création d'un processus===

Pour les système POSIX, la création d'un processus est très simple : on utilise la fonction <tt>fork()</tt>. En C, le prototype de la fonction se trouve dans le fichier d'entêtes <tt>unistd.h</tt>.

Cette fonction prend 0 argument et permet de faire la chose suivante : elle crée un nouveau processus qui est une copie conforme du processus appelant. La seule différence visible entre l'ancien et le nouveau processus est que les processus ont un numéro (PID) différent. Pour le processus appelant, il peut obtenir le PID du nouveau processus en regardant la valeur de retour de <tt>fork</tt>. Pour le nouveau processus, cette valeur vaudra 0, et il devra utiliser la fonction <tt>getpid()</tt> pour obtenir son numéro.

Le processus appelant est appelé le ''père'' alors que le nouveau processus est appelé le ''fils''.

Notez que l'espace mémoire du processus est dupliqué plutôt que partagé. Ceci veut dire que les processus ne peuvent pas communiquer en utilisant leur variables... Par contre, les descripteurs de fichiers du fils sont hérités directement de ceux du père ; ils peuvent donc essayer de communiquer en passant par ces fichiers. (Mais cela pose de nombreux problèmes de synchronisation.)

Voici par exemple un petit programme C qui lance un processus fils:
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {

int pid ;
int pid_fils ;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
} else {
printf(" >> Je suis le fils.\n");
}

return(0);

}
Après compilation, voici un exemple d'exécution du programme résultant :
$ ./pere_fils
> Le processus 8248 démarre...
>> Je suis le fils.
>> Je suis le père (pid du fils = 8249).

Voici un autre exemple d'exécution :
$ ./pere_fils
> Le processus 8269 démarre...
>> Je suis le père (pid du fils = 8270).
>> Je suis le fils.

Notez que les numéros sont différents, et que l'ordre d'affichage n'est pas le même. Cela vient de l'ordonnancement des deux processus qui peut différer.

La technique consistant à faire
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
...
}
montre que malgré le fait que les processus soient identiques à l'origine, on peut faire beaucoup de chose.

:'''Remarque :''' <tt>fork()</tt> n'est pas directement un appel système, mais une fonction qui utilise l'appel système <tt>clone()</tt>. Cet appel système ne fait pas partie de la norme POSIX...

La deuxième technique utilisée dans les systèmes POSIX consiste à utiliser <tt>fork()</tt> pour dupliquer le processus, puis à complètement remplacer le fils par un nouveau processus. La fonction correspondante est la fonction <tt>execv</tt> :
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
execv("/usr/bin/...", argv);
...
}
La fonction <tt>execv</tt> prend 2 arguments : une chaîne contenant le chemin d'accès à un programme, et un tableau d'arguments à donner au programme. (C'est un peu plus compliqué que ça : le premier élément du tableau est le nom du programme, et le tableau doit se terminer par un pointeur NULL.)

Une dernière fonction importante est la fonction <tt>wait(pid)</tt> qui permet à un processus d'attendre l'arrêt du processus <tt>pid</tt>.

-- ...

L'API WIN32 possède de nombreuses fonctions avec des fonctionnalités similaires. Par exemple, la fonction [http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx <tt>CreateProcess</tt>] permet de créer un nouveau processus (comme un <tt>fork</tt> suivi d'un <tt>exec</tt>), mais elle nécessite ... 10 arguments !

----

Un autre moyen de créer des processus est d'utiliser des 'processus légers' appelés Thread. Ces processus légers partage seulement une partie de la mémoire, ce qui en pratique est plus rapide pour simuler un parallélisme. On passe alors par une autre fonction. Sous GNU/Linux, lors de l'écriture d'un programme écrit en C il faut utiliser la bibliothèque pthread.h et lors de la compilation, faire un lien vers celle ci, en utilisant le paramètre -lpthread.

====Arborescence des processus dans les systèmes POSIX====

Nous avons vu que la fonction <tt>fork()</tt> permet de créer un processus fils. Le père connaît le PID de son fils : il lui est donné par la fonction <tt>fork()</tt>. Comme le fils peut lui même créer des processus fils, on obtient rapidement une arborescence de processus.

Vous pouvez visualiser cette arborescence à partir d'un terminal avec la commande <tt>pstree</tt> (l'option <tt>-p</tt> permet de demander l'affichage des PID)
$ pstree -p
init(1)─┬─acpid(25425)
├─atd(14365)
├─console-kit-dae(3632)─┬─{console-kit-dae}(3633)
│ ├─{console-kit-dae}(3641)
...
├─cron(14315)
├─dbus-daemon(15590)
├─dbus-daemon(3511)
...
├─getty(4095)
├─getty(4096)
├─getty(4097)
├─getty(4098)
├─getty(4099)
├─gpm(3528)
...
├─kded4(15769)
├─kdeinit4(15766)───klauncher(15767)
├─kdm(15564)─┬─Xorg(15566)
│ └─kdm(15573)───sh(15608)─┬─conky(15751)
│ ├─fluxbox(15703)───firefox-bin(6063)─┬─{firefox-bin}(6064)
│ │ ├─{firefox-bin}(6065)
...
│ ├─ssh-agent(15698)
│ ├─unclutter(15742)
│ ├─wicd-client(15749)
│ └─xscreensaver(15683)
...
├─rsyslogd(6850)─┬─{rsyslogd}(6140)
│ └─{rsyslogd}(6141)
├─screen(4427)─┬─bash(4428)───pstree(9307)
│ ├─bash(4429)───man(7952)───pager(7965)
│ ├─bash(4430)───vi(30568)
│ ├─bash(18395)───vi(28512)
│ └─mutt(8763)
...

Le processus <tt>init</tt> est l'ancêtre de tout les processus, il a toujours 1 comme PID.

'''Remarque :''' sous Windows, les processus ne sont pas organisé en arborescence...

====Mort d'un processus dans un système POSIX====

Un processus peut se terminer pour plusieurs raisons :
* volontairement, grâce à la fonction <tt>exit()</tt> (POSIX) ou <tt>ExitProcess()</tt> (Windows),
* à cause d'une erreur,
* en recevant un signal d'un autre processus, grâce à la fonction <tt>kill()</tt> (POSIX) ou <tt>TerminateProcess()</tt> (Windows).

Lorsqu'un processus se termine, plusieurs choix sont possibles :
* que fait-on de ses fils ?
* que fait-on de son père ?

Linux fait la chose suivante : quand un processus s'arrête,
* tous ces fils s'arrêtent,
* son père reçoit un signal le prévenant que son fils vient de mourir.

Pour que le père puisse recevoir le signal correspondant, il faut qu'il utilise la fonction <tt>wait()</tt> ou <tt>waitpid()</tt>. Tant que le parent existe et qu'il n'a pas reçu le signal disant qu'un de ces fils est mort, le processus fils n'est pas entièrement supprimé : il devient un ''zombie''. (Il n'occupe plus vraiment de place en mémoire, mais le système garde juste suffisamment d'information pour pouvoir prévenir le père si celui ci demande l'état du fils.)

'''Remarque :''' les processus Windows ne sont pas organisés sous forme d'arborescence. Chaque processus peut surveiller l'état d'un autre processus, s'il connaît son PID. Il n'y a donc pas de notion de processus ''zombie'' sous Windows.

Voici un petit programme C qui crée un processus fils, ne fait rien pendant 20 secondes, puis demande l'état de son fils :
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
int pid ;
int pid_fils ;
int w;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
printf(" >> Je suis le père et j'attends un peu.\n");
sleep(20);
printf(" >> Je suis le père et je demande l'état de mon fils.\n");
wait(&w);
printf(" >> Mon fils est mort (signal %i).\n", w);
while(1) sleep(1);
} else {
printf(" >> Je suis le fils.\n");
while (1) sleep(1);
exit(0);
}
return(0);
}
Si on tue le processus fils pendant que le père ne fait rien, le processus fils devient un zombie. Dès que le père fait le <tt>wait</tt>, il reçoit la valeur du signal qui a terminé le processus et le zombie disparaît.

Si on ne tue pas le processus fils, le père n'exécutera jamais le <tt>printf(" >> Mon fils est mort...);</tt>.

'''Remarque :''' dans un système POSIX, lorsqu'un processus meurt, ses fils deviennent ''orphelins''. Il continuent leur exécution mais sont adopté par <tt>init</tt> (PID : 1). Dans certains cas lorsque le processus est arrêté, il envoie explicitement un signal <tt>SIGTERM</tt> pour tuer ses processus fils. C'est par exemple ce qui arrive lorsqu'on lance des application à partir d'un terminal et que l'on quitte le terminal en question...

===États d'un processus===

On peut imaginer un SE dans lequel les processus pourraient être dans trois états :
* en cours d'exécution,
*bloqué : il attend un événement extérieur pour pouvoir continuer (par exemple une ressource; lorsque la ressource est disponible, il passe à l'état "prêt")
*prêt : suspendu provisoirement pour permettre l'exécution d'un autre processus.

Dans un système avec un unique processeur, au plus un processus peut se trouver dans l'état ''en cours d'exécution''. Par contre, il peut y avoir de nombreux processus dans l'état ''bloqué'' ou dans l'état ''prêt''.

Un processus peut passer d'un état à l'autre :
# de ''en exécution'' à ''bloqué'' lorsqu'une ressource n'est pas disponible (entrées / sortie par exemple),
# de ''bloqué'' à ''prêt'' si la ressource ayant provoqué le blocage devient disponible,
# de ''en exécution'' à ''prêt'' si le système décide de suspendre l'exécution du processus,
# de ''prêt'' à ''en exécution'' si le système décide de lancer l'exécution du processus.

On peut résumer ceci par le graphe de transitions suivant :

[[Image:Diagrammedétatdunprocessus.png]]

Les transition manquantes ne sont pas possible directement mais doivent passer par des transition intermédiaires.

On peut ajouter 2 états :
* ''nouveau'' pour un processus qui vient d'être créé,
* ''terminé'' pour un processus qui vient de se terminé.

Dans les systèmes type ''ordinateur de bureau'', le passage de ''nouveau'' à ''prêt'' est automatique mais dans des systèmes temps réel, un processus peut parfois attendre dans cet état.

L'état ''terminé'' est en général passager. Par exemple, lorsqu'un processus terminé est un zombie, le processus n'est conservé que dans la table des processus. La mémoire utilisé par le processus est libérée. La question de savoir si ceci est véritablement un état du processus est donc essentiellement une question de vocabulaire.

:exercice : ajouter les états ''nouveau'' et ''terminé'' et les transitions correspondantes au graphe précédent. Identifiez des situations provoquant les transitions possibles entre états.

===Ordonnancement des processus===

Nous avons vu qu'il pouvait y avoir de nombreux processus dans la table de processus (environ 150 sur mon ordinateur en ce moment même). Parmi ces processus, un seul (sur une machine à un processeur) peut se trouver dans l'état ''en exécution''. C'est au système d'exploitation de décider qui, à un moment donnée, doit se trouver dans cet état. La partie du système faisant ceci s'appelle ''ordonnanceur'' (ou ''scheduler'' en anglais).
En utilisant le contenu de la table des processus et éventuellement d'autres information, ordonnanceur doit donc gérer les transition entre états de tous les processus, et envoyer l'information nécessaire aux composants adéquat du noyau.

Comme d'habitude, l'ordonnanceur doit faire des compromis entre :
* la vitesse,
* l'utilisation de la mémoire,
* l'optimalité de la solution proposée.

'''Remarque : ''' l'ordonnanceur est lui même un processus (ou un morceau de processus dans le cas des noyaux monolithiques).

====Ordonnancement non préemptif====

'''FIFO.'''
L'algorithme d'ordonnancement le plus facile est probablement celui de type ''FIFO'' : premier arrivé, premier servi. Autrement dit, on préempte premier processus arrivé, et on l'exécute jusqu'à la fin. La seul structure de donnée est donc simplement une ''file''.

'''Plus court temps d'exécution.'''
Dans certain cas, on peut prévoir a l'avance le temps processeur dont aura besoin un processus pour s'exécuter. On peut alors choisir le processus le plus court et l'exécuter en premier. Ceci a en général tendance à diminuer le temps d'attente moyen d'un processus ; mais si des processus courts sont crées régulièrement, on peut assister à une ''famine'' : un processus peut ne jamais s'exécuter.

:exercice : trouver une suite de processus qui provoque une famine.

Ces deux exemples sont acceptables pour un ''traitement par lots'' (batch) par exemple pour des calculs numériques. Ils ne sont par contre pas du tout adaptés pour un ordinateur personnel ou un système temps réels. (Pas de ''multiprogrammation''.)

====Ordonnancement préemptif====

Pour pouvoir donner l'illusion de simultanéité, les processus sont en général exécutés par tranches de temps spécifiées à l'avance (''time slice'' en anglais). Au bout de ce temps, le noyau reçoit une interruption et examine les processus. Il peut décider de continuer le processus courant, ou bien le remplacer par un autre processus. on parle de préemption.

Windows 3.1 ou MacOS 9 étaient des systèmes ''collaboratifs'' car les processus devaient explicitement laisser la main aux autres processus. Tous les systèmes d'exploitation modernes sont maintenant préemptifs. On parle maintenant de système préemptif lorsque la préemption peut s'effectuer même sur des processus en mode noyau.
On parle parfois de noyau préemptible lorsque que les opérations en mode noyau sont elle même préemptibles.

'''Tourniquet.'''
L'algorithme le plus simple est probablement celui du tourniquet (''round Robin'' en anglais). C'est une variante de l'algorithme FIFO vu plus haut, mais qui préempte le processus courant au bout d'un moment. Si ce processus est encore en exécution, on le remet à la fin de la file des processus.

Le temps imparti à chaque processus ne doit pas être trop court (sinon, le changement de contexte prend trop de temps par rapport à l'exécution des processus) ni trop long (sinon, on perd l'illusion de parallélisme, et un processus bloqué risque d'occuper le processeur pendant trop longtemps).

Voici ce qu'on peut trouver dans le livre "Understanding the Linux kernel" :

<cite>
The choice of quantum duration is always a compromise. The rule of thumb adopted by Linux is: choose a duration as long as possible, while keeping good system response time.
</cite>

(extrait du chapitre [http://oreilly.com/catalog/linuxkernel/chapter/ch10.html "Process Scheduling"]).

'''Tourniquet avec priorité.'''
Tous les processus ne naissent pas égaux : certains ont une importance plus élevée (les processus systèmes par exemple). Dans un cas comme le précédent, tous les processus ont le même statut...
Pour corriger ce problème, on utilise parfois un algorithme similaire, mais on choisit le premier processus de priorité la plus élevé possible. Plutôt que de parcourir la file à sa rechercher, on utilise en fait plusieurs files : une pour chaque priorité.

Il faut faire attention car les processus de priorité basse risquent de ne jamais être exécutés (famine)... Par exemple, on peut diminuer petit à petit la priorité des processus qu'on exécute...

Une autre solution pour gérer les priorité en évitant certaines famines est d'exécuter toutes les files, mais pas en proportion égale. Par exemple, on choisit un processus dans les piles de priorité 1, 2, 1, 3, 1, 2, 1, 4, 1, 2, 1, 3, 1, 2, 1, ... De cette manière, les processus de la première file sont exécutés 2 fois plus de fois que ceux de la file 2, et 4 fois plus de fois que ceux de la file 3.

:exercice : donnez un algorithme pour générer la suite précédente pour un nombre donné de files. Il faut que la file ''i'' soit utilisée 2 fois plus souvent que la pile ''i+1''.

'''Répartition garantie.'''
Chaque tache reçoit la même proportion du processeur, et chaque utilisateur reçoit la même proportion également.

'''tirage aléatoire.'''
À chaque étape, on tire un "billet" au hasard, et le processus qui a le "billet gagnant" s'exécute.

Principe de priorité : Les processus qui ont été définit comme prioritaire on plus de "billet" à leur nom et ont donc plus de chance d'être tiré.

''NB : POSIX définit une commande "nice" qui permet e donner à un processus un priorité plus faible (et par conséquent, nice -x augmente cette priorité). Il est évident que tout le monde ne doit pas pouvoir utiliser cette commande, il vaut mieux que l'administrateur se réserve ce droit''

'''Ordonnancement équitable.'''

==La mémoire==

===Introduction===

RAM = Random Acces Memory. C'est ce que l'on appelle couramment la mémoire vive, elle peut être modifié à l'infini et sert à stocker temporairement les fichiers que l'ordinateur exécute.

ROM = Read Only Memory. On l'appelle aussi mémoire fixe ou mémoire morte, dès que l'on enregistre, le contenu d'une mémoire ROM ne peut pas être modifié (ex: un CD-ROM).

'''Gestion de la mémoire : '''

Lors du boot du PC, le système est chargé en mémoire.
Tout processus créé est aussi chargé dans la mémoire.

Lorsque l'on créé uns seul processus, il est plus pratique de le charger en "bas" de la mémoire, à partir de la première case de l'espace mémoire. Puis les nouveaux processus peuvent être charger par dessus. Ainsi la machine comprend où commence l'espace mémoire.

Problèmes :
1 - l'espace d'adressage ne commence pas à 0;
2 - un processus peut demander dynamiquement de la mémoire;
3 - avec un accès direct, un processus peut faire "planter" un autre.

==> Il faut avoir une couche d'abstraction au-dessus de la mémoire physique.

===Espaces d'adressage===

Et si l'on créait des espaces d'adressage distincts pour chaque processus ?
Par exemple : chaque processus utilise des adresse de 0 à n de la mémoire, on converti alors ces adresses en adresses physiques.

Certains des premiers processeurs avaient deux registres supérieurs :

- une Base => adresse physique du début de l'espace d'adressage

- une Limite => adresse physique de fin de l'espace d'adressage

Par exemple, lors de l'exécution d'un processus l'accès à une case "a" se transforme en l'accès à la Base+a et un test pour vérifier que : a+Base < Limite.

Malgré tout, ceci ne résout pas les problèmes liés au fait que des processus sont créés et disparaissent, réclament ou libèrent de la mémoire.

===Va-et-vient (swapping)===

====Idée====

Et si pour gérer tout cela on utilisait une mémoire auxiliaire (disque), pour stocker l'état de la mémoire de processus.

La mémoire vue par les processus ne correspond pas à la mémoire physique. À un instant donné, certains processus peuvent se retrouver sur le disque (dans le SWAP).

Quand un processus apparait, on lui cherche un morceau d'espace libre dans la mémoire.

====gestion de la mémoire====

* tableau de bits
* liste chaînée

====Allocation====

* first fit
* next fit
* best fit
* worst fit

===Mémoire virtuelle===

====Idée====

====Pagination====

====Traduction des adresses====

====Table des pages====

====Table inversée====

====Remplacement des pages====

==Les entrées / sorties==

----
----

==Références==

* le livre « Systèmes d'exploitation » de Andrew Tanenbaum est disponible à la BU
* la page du [http://sos.enix.org/fr/PagePrincipale projet SOS]
* la [http://www.opengroup.org/onlinepubs/009695399/nfindex.html norme POSIX:2004]
* l'[http://msdn.microsoft.com/en-us/library/aa383749(VS.85).aspx API win32]
* [http://www.lemis.com/grog/Documentation/Lions/index.php Commentary on the Sixth Edition UNIX Operating System]

INFO502 : Systèmes d'exploitation

2009-12-01T10:48:09Z

Hatat : /* TP */

Ce wiki est un complément de cours pour le cours « info-502 : systèmes d'exploitation ». La participation au wiki est fortement encouragée.

Pour pouvoir modifier les pages, inscrivez-vous (lien en haut à droite) pour obtenir un login et mot de passe. (Choisissez un login du style ''PrenomNom''...)

Je vous conseille d'aller lire [http://meta.wikimedia.org/wiki/Aide:Contenu ce guide] pour vous familiariser avec les wikis.

Exercice : si vous n'en avez pas, créez-vous un compte et essayez de modifier cette page (correction de fautes d'hortographe, rajout de détails, mise en page, ...)

Vous pouvez aussi utiliser la page de discussion pour ... discuter. (Ou poser des questions, faire des commentaires etc.)

----
----
==Auteur du cours==

===Nouvelles===

===Supports===

====TD====

Sujets de TD :
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td1.pdf Ordonnancement],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td2.pdf Gestion de la mémoire],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td3.pdf Systèmes de fichiers].

====TP====

# Découverte de SOS :
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp1.pdf sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp1.tar.gz code source].
# Gestion de la mémoire du noyau.

==Introduction==

-- ...

==Repères historiques==

Voici quelques évènements clés dans l'histoire des systèmes d'exploitation. Pour plus de détails, ou pour des compléments sur l'histoire de l'informatique, je vous renvoie sur Wikipedia : [http://en.wikipedia.org/wiki/History_of_operating_systems "History of operating systems"] et [http://en.wikipedia.org/wiki/History_of_computing "History of computing"].

Les premiers ordinateurs ne comportaient pas vraiment de système d'exploitation : c'étaient des opérateurs humains qui géraient tout. (C'était juste après la seconde guerre mondiale, l faut savoir que les langages de programmation n'existaient même pas...) La petite histoire (??) raconte qu'à un moment, les processus pour l'ordinateur de l'université de Cambridge étaient accrochés sur une corde à linge et que c'était la couleur des pinces à linges qui donnait la priorité. (??)

Le passage à la notion de système d'exploitation c'est faite graduellement pour répondre à la complexité de plus en plus grande des ordinateurs et aux demandes des utilisateurs.

Les premier systèmes d'exploitation datent probablement de 1956. Ils permettaient simplement d'exécuter un nouveau programme lorsque le précédent était terminé. Les ordinateurs d'IBM de la famille System/360 ont ensuite eu toute une série de systèmes d'exploitation plus ou moins similaires : OS/360, DOS/360 (rien à voir avec MS-DOS), TSS/360... C'est à cette époque qu'est apparu la notion de multiprogrammation (possibilité d'avoir plusieurs processus entrelacés.)
C'est également au début des années 60 qu'on a commencé à voir des systèmes avec temps partagé : plusieurs utilisateurs pouvaient utiliser un ordinateur. Le système Multics a été, à ce niveau comme à d'autres, assez révolutionnaire. Multics a été utilisé jusqu'en 2000 !

Multics n'était par contre pas approprié pour les mini-ordinateurs où le nombre d'utilisateur est relativement restreint. En 1969, Ken Thomson
a développé une variante simplifié de Multix : Unix...

Ce n'est qu'un peu plus tard (1979) que la première version de DOS (86-DOS ou QDOS) apparaît. 86-DOS sera racheté par Microsoft un 1980...

'''Liens et compléments :'''
* [http://en.wikipedia.org/wiki/Timeline_of_operating_systems Timeline of operating systems]
* généalogie des systèmes Unix : [http://www.levenez.com/unix/ Unix History]
* généalogie de Windows : [http://www.levenez.com/windows/ Windows History]
* généalogie des systèmes non-Unix : [http://www.oshistory.net/metadot/index.pl?id=2165 timeline of non-Unix operating systems]

==Vue d'ensemble==

Ce cours reste assez généraliste et essaie de regarder les principales fonction d'un système d'exploitation. Les systèmes de type Unix (Linux) sera un exemple privilégié. À cause de leur complexité intrinsèque, les évolutions modernes (architectures multicoeur ou multiprocesseur, ...) seront en partie ignorée dans un premier temps.

Les problèmes fins de communication entres processus ne seront que très peu abordés, car ils font l'objet d'un cours séparé (info604) pour la filière info.

Nous allons suivre l'ordre classique consistant à regarder :
# les processus
# la mémoire
# les entrées / sorties

La fin du cours dépendra du temps restant...

===Les processus===

Un processus est simplement un programme « en exécution ». À tout instant, un ordinateur de bureau contemporain contient de nombreux processus qui doivent partager le (les) processeur(s) pour donner l'impression qu'ils s'exécutent « en même temps ». Un des rôles du système d'exploitation consiste à décider dans quel ordre les processus vont effectivement pouvoir utiliser le processus.

===La mémoire===

La mémoire est, comme le processeur, une ressource partagée par les différents processus. Il faut donc gérer la quantité de mémoire allouée et utilisée pour que les processus n'aient pas à s'occuper de ceci. Un des concepts fondamentaux est celui de mémoire virtuelle. Ceci permet d'offrir un espace mémoire pour chacun des processus de manière transparente.

===Les entrées / sorties===

Un ordinateur n'est pas (plus) un système indépendant du reste du monde : il interagit avec l'extérieur à travers des périphériques d'entrées/sorties (clavier / écran / souris / ...). La gestion de ces périphériques pose un ensemble de problèmes que nous aborderons brièvement...

===...===

Une fois ces notions vues, nous regarderons peut-être les problèmes de sécurité, de multimédia ou des architectures multiprocesseurs.

==Préliminaires==

===Quoi ?===

Les ordinateurs, ou plus simplement les micro contrôleurs sont des circuits électroniques avec une puce « processeur ». Le développement d'applications n'est pas facile si on se place au niveau électronique et que l'on parle directement au CPU. Pour faciliter la vie des programmeurs, plusieurs couches d'abstraction sont nécessaires. La première se place au niveau matériel et s'occupe directement des problèmes électroniques ou de très bas niveau. Il s'agit du ''firmware''. Il répond par exemple aux questions comme :
* qu'elle est l'amplitude des signaux envoyés par l'horloge ?
* est-ce que l'UC possède un pipeline ?
* ...
Un firmware est donc forcement très lié au matériel sur lequel il tourne.

La couche suivante est le système d'exploitation à proprement parler. Dans le cas que vous connaissez le mieux (ordinateur personnel), le système d'exploitation fournit une interface pour :
* exécuter un programme
* exécuter plusieurs programmes « en même temps »
* gérer les ressources (temps processeur, mémoire disponible, entrées / sorties)
* les opérations sur les fichiers
* offrir des garanties de sécurité

===Où ?===

On trouve des systèmes d'exploitation partout :

* dans les ordinateurs personnels (Linux, BSD, MacOS, Solaris, Windows, ChromeOS (?))
* dans les PDA (PalmOS, ...)
* dans les téléphones portables (Android, OpenMoko,Symbian,)
* console de jeux
* lecteur MP3 (Rockbox, ...)
* les microcontroleurs « avancés »

===Comment ?===

====Langage de programmation====

Le système d'exploitation se situe entre le firmware (très bas niveau) et l'utilisateur. La nécessité d'accéder à ces ressources de très bas niveau implique que les langages de haut niveaux (Java, Ada, Python, ...) ne sont pas du tout adaptés à l'écriture des systèmes d'exploitation.
Le langage le plus utilisé reste à ce jours le langage C : Linux, BSD, MacOS, Windows, ... sont tous écrits pour leur plus grande partie en C.

Vous avez normalement un cours de C en parallèle, et les TPs utiliseront le langage C. (La référence sur le langage C reste à mon goût le livre de Kernighan et Ritchie : « the C Programming language ». (Disponible en francais à la BU sous le titre « Le langage C : norme Ansi ».) Il existe de nombreux autres livres / documents sur la programmation C comme le [http://www-clips.imag.fr/commun/bernard.cassagne/Introduction_ANSI_C.html polycopié de Bernard Cassagne « introduction au langage C »].

Les premiers systèmes d'exploitation étaient écrits directement en langage machine, ou bien en langage d'assembleur ; et les systèmes actuels comportent encore quelques parties de très bas niveau en langage d'assemblage...

====Notion d'appel système, norme POSIX====

La programmation de haut niveau en C est assez différente de la programmation système. De nombreuses fonctions C utilisent en fait des « appels système », c'est à dire des appels de fonctionnalités propres du système d'exploitation. Les appels système typiques sont :
* les fonctions relatives aux fichiers (création, suppression, modification...)
* les fonctions relatives à la gestion de la mémoire
* les fonctions relatives aux processus (<tt>fork</tt>)
* ...

De nombreux système d'exploitation proposent une interface [http://en.wikipedia.org/wiki/Posix POSIX] (« '''P'''ortable '''O'''perating '''S'''ystem '''I'''nterface for Uni'''x''' »). Cette norme définit entre autres un ensemble de fonctions pour utiliser les appels systèmes.
Le nombre de ces fonctions est relativement faible : une centaine ; et chacune correspond en gros à un appel système. Certaines de ces fonctions ne sont pas définies directement dans le système d'exploitation, mais dans des librairies. Pour Linux, il s'agit en général de la librairie Glibc (GNU C Library).

Par exemple, la fonction <tt>open</tt> (qui permet d'ouvrir un fichier) correspond exactement à un appel système ; alors que la fonction <tt>malloc</tt> (qui permet d'allouer dynamiquement de la mémoire dans le tas) peut générer plusieurs appels système (<tt>brk</tt> et <tt>sbrk</tt>).

Pour visualiser les appels systèmes effectués par un programme sous Linux, vous pouvez utilisez l'utilitaire <tt>strace</tt> ou <tt>ltrace</tt>. Par exemple, dans le shell :
$ strace -e trace=file ls -l 2> trace
permet de récupérer tous les appels systèmes relatifs aux fichiers lors de l'appel à <tt>ls -l</tt>. La liste des appels système est redirigée dans le fichier <tt>trace</tt> qui contiendra par exemple des lignes telles que
lstat64("Desktop", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lgetxattr("Desktop", "security.selinux", 0x8cc08e0, 255) = -1 ENODATA (No data available)
dénotant ainsi un appel aux appels système <tt>lstat64</tt> et <tt>lgetxattr</tt>...

Les principaux systèmes compatibles POSIX sont :
* Linux
* BSD (et variantes)
* Mac OS X
* Solaris

De nombreux appels systèmes sont disponibles directement (sans avoir besoin d'écrire un programme C) à travers le shell. Exécuté dans un terminal, le shell permet, en première approximation, de passer directement des commandes au système d'exploitation. (La norme POSIX définit également un ensemble de fonctions du shell. Il est donc relativement aisé de changer de système d'exploitation tant qu'on reste dans les systèmes compatibles POSIX.)

Windows d'un autre côté utilise l'interface Win32 API, qui définit plusieurs milliers de fonctions. La plupart de ces fonctions peuvent utiliser plusieurs appels système...

Les systèmes d'exploitation qui utilisent l'API Win32 sont :
* Windows, depuis Windows95.

Il est possible d'installer un environnement compatible POSIX sur une machine Windows grâce à Cygwin. (C'est d'ailleurs fortement conseillé si vous ne voulez pas installer une version de Linux ou BSD sur votre ordinateur personnel...)

====Mode noyau / mode utilisateur====

La partie fondamentale du système d'exploitation est le ''noyau'' (''kernel'' en anglais). C'est la couche de plus bas niveau.

Les fonctionnalités de très bas niveau offertes par le noyau peuvent facilement planter l'ordinateur. Il faut donc une politique de restriction pour que tous les programmes ne puissent y accéder dans leur totalité. On parle de
* mode noyau
* mode utilisateur

Dans le mode utilisateur, on ne peut accéder à ces fonctionnalités qu'a travers les appels systèmes ; dans le mode noyau, on peut tout faire... Bien entendu, un appel système doit passer momentanément en mode noyau pour pouvoir exécuter les commandes pertinentes, puis il repasse automatiquement en mode utilisateur.

La définition d'un appel système pourrait donc être « fonctionnalité atomique nécessitant un passage en mode noyau ».

====Noyau, noyau monolithique, micro-noyau====

La partie principale du système d'exploitation. C'est lui qui gère les ressources, les entrées / sorties, la communication entre processus, ... Les deux architectures principales pour un noyau sont :
* noyau monolithique
* micro-noyau
La plupart des systèmes actuels sont basés sur un noyau monolithique (Linux, BSD, Mac OS X, Solaris, Windows).

Les noyaux monolithiques sont parfois décrits comme « sans vraie structure » : une grosse soupe où cohabitent toutes les fonctionnalités du système d'exploitation. L'idée d'avoir un système unique qui gère tout est effectivement peu attirante et peut poser quelques problèmes de génie logiciel...
Un noyau monolithique est donc la couche entre le matériel et les programmes utilisateurs. Pour éviter de compiler des noyaux énormes, les noyaux monolithiques actuels utilisent en plus la notion de ''module''. Ce sont des morceaux du noyau qu'on peut charger ou décharger au besoin. Si l'interface est connue, ces modules peuvent éventuellement être en binaire, ce qui permet d'utiliser des modules propriétaires avec un noyau libre.
Sous Linux, la commande
$ lsmod
permet d'obtenir la liste des modules chargés dans le noyau.

Les micro-noyaux d'un autre coté sont basés sur la remarque que seule une toute petite partie du noyau accède effectivement au matériel. Seule cette petite partie nécessite donc des privilèges et effectue des appels système. Le reste du système d'exploitation peut être programmé en mode utilisateur, « au dessus » de cette partie. Par exemple, le micro noyau offrira la possibilité de charger un nouveau processus, mais l'ordonnanceur (qui choisit quel processus devra être chargé) ne fera pas partie du micro-noyau. On parle parfois de ''services'' / ''serveurs'' au dessus du micro-noyau.
Ceci permet d'avoir un noyau bas niveau beaucoup plus petit. Bien que ceci soit une bonne idée, et que les micro-noyaux puissent fournir de meilleurs garanties de sécurité, peu de noyaux sont effectivement des micro-noyaux. Un des problèmes est qu'un tel micro-noyau est un peu plus lent que ses cousins monolithiques. La raison principale est que dans le cas d'un micro-noyau, un appel système nécessite en fait des communications inter-processus.
Andrew Tanenbaum est un fervent défenseur des micro-noyaux.

Une autre architecture possible est d'utiliser des couches successives, chacune avec des privilèges réduits. Le système Multics avait cette architecture.
Par exemple, dans le système THE (1965), les couches étaient les suivantes :
# noyau bas niveau, multiprogrammation
# allocation de la mémoire pour les processus
# IPC (communication inter processus)
# entrées / sorties (buffer, etc.)
# programmes utilisateurs (compilation, exécution, ...)
# utilisateur (Dijkstra a annoté la description de cette couche par ''« not implemented by us »'')

Une dernière catégorie de noyau est la catégorie des machines virtuelles. Ces noyaux sont un peu à part, car il s'agit d'émuler un système d'exploitation ou du matériel particulier à l'intérieur d'un autre système d'exploitation ou matériel. Le mode noyau de la machine virtuelle est en fait dans le mode utilisateur du noyau original...

==Les processus==

===Introduction===

Allez hop commençons par une petite définition du type wikipédia :

Un processus (en anglais, process), en informatique, est défini par :
* un ensemble d'instructions à exécuter (un programme) ;
* un espace mémoire pour les données de travail ;
* éventuellement, d'autres ressources, comme des descripteurs de fichiers, des ports réseau, etc.

Un ordinateur équipé d'un système d'exploitation à temps partagé est capable d'exécuter plusieurs processus de façon « quasi- simultanée ». Par analogie avec les télécommunications, on nomme multiplexage (A. Tanenbaum parle de ''multiprogrammation'') ce procédé. S'il y a plusieurs processeurs, le système essaie de répartir les processus de manière équitable sur les processeurs disponibles.

Le processus doit être imaginé comme quelque chose qui prend du temps, donc qui a un début et (parfois) une fin. De nombreux processus ne se terminent normalement jamais : système d'exploitation, serveurs web, serveurs mail, ... D'autres processus plus légers qui ne se terminent pas sont les ''daemon'' (acronyme ''a posteriori'' de "disk and execution monitor") du monde Unix.

Certains processus sont démarrés très tôt lors de la séquence de boot. Le système d'exploitation est un tel processus. Sinon, les processus sont normalement démarrés grâce à un appel système à partir d'un autre processus. L'utilisateur peut par exemple demander explicitement un nouveau processus (sous POSIX, grâce à un <tt>fork</tt> puis <tt>exec</tt>) ; mais la plupart du temps, il le fera à travers une application, par exemple en double-cliquant sur l'icône d'un programme dans l'explorateur de fichiers.

Le système d'exploitation est chargé d'allouer les ressources (mémoires, temps processeur, entrées/sorties) nécessaires aux processus et d'assurer que le fonctionnement d'un processus n'interfère pas avec celui des autres (isolation).

Pas sûr d'avoir tout compris ? Ce n'est pas grave, essayons autrement.
:'''Définition :''' un processus est un programme en train de s'exécuter.
Cette définition implique en particulier que un programme (navigateur Firefox par exemple) peut correspondre à
* zéro processus si on ne l'a pas lancé,
* un processus si on l'a lancé,
* plusieurs processus si on l'a lancé plusieurs fois.
(''Remarque :'' pour un programme comme Firefox, il y a fort à parier que l'exécution d'une seule instance de Firefox génère de multiples sous-processus...)

Que se passe-t-il quand je démarre une application?

:L'ordinateur à une nouvelle tâche à accomplir, les instructions correspondantes sont donc envoyées au processeur. Comme il a plusieurs choses à faire le choix des instructions à exécuter n'est pas forcement simple. Il faut faire en sorte de partager le processeur entre les différentes tâches de manière équitable : c'est la fameuse gestion des processus.
:Ceci permet de réaliser plusieurs activités en ~même temps~. Grâce à la gestion des processus on peut regarder un film (obtenu par des moyens tout à fait légaux cela va de soit), tout en jouant à la dame de pique.
:(et dire que certain(e)s affirment que l'homme est mono tâche)

Plusieurs processus indépendants peuvent être ''actifs'' en même temps, mais sauf si l'ordinateur possède suffisamment de processeurs, on ne peut pas les exécuter simultanément. L'impression que plusieurs programmes s'exécutent ''en même temps'' vient simplement du fait que le processeur alterne rapidement entre eux.
Comme le temps d'exécution d'une instruction par le processeur est très court, de l'ordre de la nano-seconde, le processeur peut réaliser plusieurs centaines de millions d'instructions par seconde. Ainsi, une tranche de temps de quelques fractions de seconde, partagée entre plusieurs processus, donne à l'échelle macroscopique l'illusion de la simultanéité.

'''En résumé :''' un système d'exploitation doit la plupart du temps traiter plusieurs tâches en même temps, et comme il n'a, en général, qu'un seul processeur, il devra contourner ce problème grâce à un pseudo-parallélisme. Il traite une tâche à la fois, s'interrompt et passe à la suivante. La commutation de tâches étant très rapide, il donne l'illusion d'effectuer un traitement simultané.

===La table des processus===

L'information sur les processus est conservé par le système dans une structure de données appelée ''table des processus''. Cette table contient toutes les informations nécessaires à la gestion des processus :
* état du processus
* PID
* droits
* répertoire de travail
* pointeur vers la pile
* priorités
* ...

Sous Linux, on peut accéder à ces informations à travers le système de fichiers virtuel "Procfs". Il suffit d'aller dans le répertoire <tt>/proc/</tt>.

===Création d'un processus===

Pour les système POSIX, la création d'un processus est très simple : on utilise la fonction <tt>fork()</tt>. En C, le prototype de la fonction se trouve dans le fichier d'entêtes <tt>unistd.h</tt>.

Cette fonction prend 0 argument et permet de faire la chose suivante : elle crée un nouveau processus qui est une copie conforme du processus appelant. La seule différence visible entre l'ancien et le nouveau processus est que les processus ont un numéro (PID) différent. Pour le processus appelant, il peut obtenir le PID du nouveau processus en regardant la valeur de retour de <tt>fork</tt>. Pour le nouveau processus, cette valeur vaudra 0, et il devra utiliser la fonction <tt>getpid()</tt> pour obtenir son numéro.

Le processus appelant est appelé le ''père'' alors que le nouveau processus est appelé le ''fils''.

Notez que l'espace mémoire du processus est dupliqué plutôt que partagé. Ceci veut dire que les processus ne peuvent pas communiquer en utilisant leur variables... Par contre, les descripteurs de fichiers du fils sont hérités directement de ceux du père ; ils peuvent donc essayer de communiquer en passant par ces fichiers. (Mais cela pose de nombreux problèmes de synchronisation.)

Voici par exemple un petit programme C qui lance un processus fils:
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {

int pid ;
int pid_fils ;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
} else {
printf(" >> Je suis le fils.\n");
}

return(0);

}
Après compilation, voici un exemple d'exécution du programme résultant :
$ ./pere_fils
> Le processus 8248 démarre...
>> Je suis le fils.
>> Je suis le père (pid du fils = 8249).

Voici un autre exemple d'exécution :
$ ./pere_fils
> Le processus 8269 démarre...
>> Je suis le père (pid du fils = 8270).
>> Je suis le fils.

Notez que les numéros sont différents, et que l'ordre d'affichage n'est pas le même. Cela vient de l'ordonnancement des deux processus qui peut différer.

La technique consistant à faire
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
...
}
montre que malgré le fait que les processus soient identiques à l'origine, on peut faire beaucoup de chose.

:'''Remarque :''' <tt>fork()</tt> n'est pas directement un appel système, mais une fonction qui utilise l'appel système <tt>clone()</tt>. Cet appel système ne fait pas partie de la norme POSIX...

La deuxième technique utilisée dans les systèmes POSIX consiste à utiliser <tt>fork()</tt> pour dupliquer le processus, puis à complètement remplacer le fils par un nouveau processus. La fonction correspondante est la fonction <tt>execv</tt> :
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
execv("/usr/bin/...", argv);
...
}
La fonction <tt>execv</tt> prend 2 arguments : une chaîne contenant le chemin d'accès à un programme, et un tableau d'arguments à donner au programme. (C'est un peu plus compliqué que ça : le premier élément du tableau est le nom du programme, et le tableau doit se terminer par un pointeur NULL.)

Une dernière fonction importante est la fonction <tt>wait(pid)</tt> qui permet à un processus d'attendre l'arrêt du processus <tt>pid</tt>.

-- ...

L'API WIN32 possède de nombreuses fonctions avec des fonctionnalités similaires. Par exemple, la fonction [http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx <tt>CreateProcess</tt>] permet de créer un nouveau processus (comme un <tt>fork</tt> suivi d'un <tt>exec</tt>), mais elle nécessite ... 10 arguments !

----

Un autre moyen de créer des processus est d'utiliser des 'processus légers' appelés Thread. Ces processus légers partage seulement une partie de la mémoire, ce qui en pratique est plus rapide pour simuler un parallélisme. On passe alors par une autre fonction. Sous GNU/Linux, lors de l'écriture d'un programme écrit en C il faut utiliser la bibliothèque pthread.h et lors de la compilation, faire un lien vers celle ci, en utilisant le paramètre -lpthread.

====Arborescence des processus dans les systèmes POSIX====

Nous avons vu que la fonction <tt>fork()</tt> permet de créer un processus fils. Le père connaît le PID de son fils : il lui est donné par la fonction <tt>fork()</tt>. Comme le fils peut lui même créer des processus fils, on obtient rapidement une arborescence de processus.

Vous pouvez visualiser cette arborescence à partir d'un terminal avec la commande <tt>pstree</tt> (l'option <tt>-p</tt> permet de demander l'affichage des PID)
$ pstree -p
init(1)─┬─acpid(25425)
├─atd(14365)
├─console-kit-dae(3632)─┬─{console-kit-dae}(3633)
│ ├─{console-kit-dae}(3641)
...
├─cron(14315)
├─dbus-daemon(15590)
├─dbus-daemon(3511)
...
├─getty(4095)
├─getty(4096)
├─getty(4097)
├─getty(4098)
├─getty(4099)
├─gpm(3528)
...
├─kded4(15769)
├─kdeinit4(15766)───klauncher(15767)
├─kdm(15564)─┬─Xorg(15566)
│ └─kdm(15573)───sh(15608)─┬─conky(15751)
│ ├─fluxbox(15703)───firefox-bin(6063)─┬─{firefox-bin}(6064)
│ │ ├─{firefox-bin}(6065)
...
│ ├─ssh-agent(15698)
│ ├─unclutter(15742)
│ ├─wicd-client(15749)
│ └─xscreensaver(15683)
...
├─rsyslogd(6850)─┬─{rsyslogd}(6140)
│ └─{rsyslogd}(6141)
├─screen(4427)─┬─bash(4428)───pstree(9307)
│ ├─bash(4429)───man(7952)───pager(7965)
│ ├─bash(4430)───vi(30568)
│ ├─bash(18395)───vi(28512)
│ └─mutt(8763)
...

Le processus <tt>init</tt> est l'ancêtre de tout les processus, il a toujours 1 comme PID.

'''Remarque :''' sous Windows, les processus ne sont pas organisé en arborescence...

====Mort d'un processus dans un système POSIX====

Un processus peut se terminer pour plusieurs raisons :
* volontairement, grâce à la fonction <tt>exit()</tt> (POSIX) ou <tt>ExitProcess()</tt> (Windows),
* à cause d'une erreur,
* en recevant un signal d'un autre processus, grâce à la fonction <tt>kill()</tt> (POSIX) ou <tt>TerminateProcess()</tt> (Windows).

Lorsqu'un processus se termine, plusieurs choix sont possibles :
* que fait-on de ses fils ?
* que fait-on de son père ?

Linux fait la chose suivante : quand un processus s'arrête,
* tous ces fils s'arrêtent,
* son père reçoit un signal le prévenant que son fils vient de mourir.

Pour que le père puisse recevoir le signal correspondant, il faut qu'il utilise la fonction <tt>wait()</tt> ou <tt>waitpid()</tt>. Tant que le parent existe et qu'il n'a pas reçu le signal disant qu'un de ces fils est mort, le processus fils n'est pas entièrement supprimé : il devient un ''zombie''. (Il n'occupe plus vraiment de place en mémoire, mais le système garde juste suffisamment d'information pour pouvoir prévenir le père si celui ci demande l'état du fils.)

'''Remarque :''' les processus Windows ne sont pas organisés sous forme d'arborescence. Chaque processus peut surveiller l'état d'un autre processus, s'il connaît son PID. Il n'y a donc pas de notion de processus ''zombie'' sous Windows.

Voici un petit programme C qui crée un processus fils, ne fait rien pendant 20 secondes, puis demande l'état de son fils :
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
int pid ;
int pid_fils ;
int w;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
printf(" >> Je suis le père et j'attends un peu.\n");
sleep(20);
printf(" >> Je suis le père et je demande l'état de mon fils.\n");
wait(&w);
printf(" >> Mon fils est mort (signal %i).\n", w);
while(1) sleep(1);
} else {
printf(" >> Je suis le fils.\n");
while (1) sleep(1);
exit(0);
}
return(0);
}
Si on tue le processus fils pendant que le père ne fait rien, le processus fils devient un zombie. Dès que le père fait le <tt>wait</tt>, il reçoit la valeur du signal qui a terminé le processus et le zombie disparaît.

Si on ne tue pas le processus fils, le père n'exécutera jamais le <tt>printf(" >> Mon fils est mort...);</tt>.

'''Remarque :''' dans un système POSIX, lorsqu'un processus meurt, ses fils deviennent ''orphelins''. Il continuent leur exécution mais sont adopté par <tt>init</tt> (PID : 1). Dans certains cas lorsque le processus est arrêté, il envoie explicitement un signal <tt>SIGTERM</tt> pour tuer ses processus fils. C'est par exemple ce qui arrive lorsqu'on lance des application à partir d'un terminal et que l'on quitte le terminal en question...

===États d'un processus===

On peut imaginer un SE dans lequel les processus pourraient être dans trois états :
* en cours d'exécution,
*bloqué : il attend un événement extérieur pour pouvoir continuer (par exemple une ressource; lorsque la ressource est disponible, il passe à l'état "prêt")
*prêt : suspendu provisoirement pour permettre l'exécution d'un autre processus.

Dans un système avec un unique processeur, au plus un processus peut se trouver dans l'état ''en cours d'exécution''. Par contre, il peut y avoir de nombreux processus dans l'état ''bloqué'' ou dans l'état ''prêt''.

Un processus peut passer d'un état à l'autre :
# de ''en exécution'' à ''bloqué'' lorsqu'une ressource n'est pas disponible (entrées / sortie par exemple),
# de ''bloqué'' à ''prêt'' si la ressource ayant provoqué le blocage devient disponible,
# de ''en exécution'' à ''prêt'' si le système décide de suspendre l'exécution du processus,
# de ''prêt'' à ''en exécution'' si le système décide de lancer l'exécution du processus.

On peut résumer ceci par le graphe de transitions suivant :

[[Image:Diagrammedétatdunprocessus.png]]

Les transition manquantes ne sont pas possible directement mais doivent passer par des transition intermédiaires.

On peut ajouter 2 états :
* ''nouveau'' pour un processus qui vient d'être créé,
* ''terminé'' pour un processus qui vient de se terminé.

Dans les systèmes type ''ordinateur de bureau'', le passage de ''nouveau'' à ''prêt'' est automatique mais dans des systèmes temps réel, un processus peut parfois attendre dans cet état.

L'état ''terminé'' est en général passager. Par exemple, lorsqu'un processus terminé est un zombie, le processus n'est conservé que dans la table des processus. La mémoire utilisé par le processus est libérée. La question de savoir si ceci est véritablement un état du processus est donc essentiellement une question de vocabulaire.

:exercice : ajouter les états ''nouveau'' et ''terminé'' et les transitions correspondantes au graphe précédent. Identifiez des situations provoquant les transitions possibles entre états.

===Ordonnancement des processus===

Nous avons vu qu'il pouvait y avoir de nombreux processus dans la table de processus (environ 150 sur mon ordinateur en ce moment même). Parmi ces processus, un seul (sur une machine à un processeur) peut se trouver dans l'état ''en exécution''. C'est au système d'exploitation de décider qui, à un moment donnée, doit se trouver dans cet état. La partie du système faisant ceci s'appelle ''ordonnanceur'' (ou ''scheduler'' en anglais).
En utilisant le contenu de la table des processus et éventuellement d'autres information, ordonnanceur doit donc gérer les transition entre états de tous les processus, et envoyer l'information nécessaire aux composants adéquat du noyau.

Comme d'habitude, l'ordonnanceur doit faire des compromis entre :
* la vitesse,
* l'utilisation de la mémoire,
* l'optimalité de la solution proposée.

'''Remarque : ''' l'ordonnanceur est lui même un processus (ou un morceau de processus dans le cas des noyaux monolithiques).

====Ordonnancement non préemptif====

'''FIFO.'''
L'algorithme d'ordonnancement le plus facile est probablement celui de type ''FIFO'' : premier arrivé, premier servi. Autrement dit, on préempte premier processus arrivé, et on l'exécute jusqu'à la fin. La seul structure de donnée est donc simplement une ''file''.

'''Plus court temps d'exécution.'''
Dans certain cas, on peut prévoir a l'avance le temps processeur dont aura besoin un processus pour s'exécuter. On peut alors choisir le processus le plus court et l'exécuter en premier. Ceci a en général tendance à diminuer le temps d'attente moyen d'un processus ; mais si des processus courts sont crées régulièrement, on peut assister à une ''famine'' : un processus peut ne jamais s'exécuter.

:exercice : trouver une suite de processus qui provoque une famine.

Ces deux exemples sont acceptables pour un ''traitement par lots'' (batch) par exemple pour des calculs numériques. Ils ne sont par contre pas du tout adaptés pour un ordinateur personnel ou un système temps réels. (Pas de ''multiprogrammation''.)

====Ordonnancement préemptif====

Pour pouvoir donner l'illusion de simultanéité, les processus sont en général exécutés par tranches de temps spécifiées à l'avance (''time slice'' en anglais). Au bout de ce temps, le noyau reçoit une interruption et examine les processus. Il peut décider de continuer le processus courant, ou bien le remplacer par un autre processus. on parle de préemption.

Windows 3.1 ou MacOS 9 étaient des systèmes ''collaboratifs'' car les processus devaient explicitement laisser la main aux autres processus. Tous les systèmes d'exploitation modernes sont maintenant préemptifs. On parle maintenant de système préemptif lorsque la préemption peut s'effectuer même sur des processus en mode noyau.
On parle parfois de noyau préemptible lorsque que les opérations en mode noyau sont elle même préemptibles.

'''Tourniquet.'''
L'algorithme le plus simple est probablement celui du tourniquet (''round Robin'' en anglais). C'est une variante de l'algorithme FIFO vu plus haut, mais qui préempte le processus courant au bout d'un moment. Si ce processus est encore en exécution, on le remet à la fin de la file des processus.

Le temps imparti à chaque processus ne doit pas être trop court (sinon, le changement de contexte prend trop de temps par rapport à l'exécution des processus) ni trop long (sinon, on perd l'illusion de parallélisme, et un processus bloqué risque d'occuper le processeur pendant trop longtemps).

Voici ce qu'on peut trouver dans le livre "Understanding the Linux kernel" :

<cite>
The choice of quantum duration is always a compromise. The rule of thumb adopted by Linux is: choose a duration as long as possible, while keeping good system response time.
</cite>

(extrait du chapitre [http://oreilly.com/catalog/linuxkernel/chapter/ch10.html "Process Scheduling"]).

'''Tourniquet avec priorité.'''
Tous les processus ne naissent pas égaux : certains ont une importance plus élevée (les processus systèmes par exemple). Dans un cas comme le précédent, tous les processus ont le même statut...
Pour corriger ce problème, on utilise parfois un algorithme similaire, mais on choisit le premier processus de priorité la plus élevé possible. Plutôt que de parcourir la file à sa rechercher, on utilise en fait plusieurs files : une pour chaque priorité.

Il faut faire attention car les processus de priorité basse risquent de ne jamais être exécutés (famine)... Par exemple, on peut diminuer petit à petit la priorité des processus qu'on exécute...

Une autre solution pour gérer les priorité en évitant certaines famines est d'exécuter toutes les files, mais pas en proportion égale. Par exemple, on choisit un processus dans les piles de priorité 1, 2, 1, 3, 1, 2, 1, 4, 1, 2, 1, 3, 1, 2, 1, ... De cette manière, les processus de la première file sont exécutés 2 fois plus de fois que ceux de la file 2, et 4 fois plus de fois que ceux de la file 3.

:exercice : donnez un algorithme pour générer la suite précédente pour un nombre donné de files. Il faut que la file ''i'' soit utilisée 2 fois plus souvent que la pile ''i+1''.

'''Répartition garantie.'''
Chaque tache reçoit la même proportion du processeur, et chaque utilisateur reçoit la même proportion également.

'''tirage aléatoire.'''
À chaque étape, on tire un "billet" au hasard, et le processus qui a le "billet gagnant" s'exécute.

Principe de priorité : Les processus qui ont été définit comme prioritaire on plus de "billet" à leur nom et ont donc plus de chance d'être tiré.

''NB : POSIX définit une commande "nice" qui permet e donner à un processus un priorité plus faible (et par conséquent, nice -x augmente cette priorité). Il est évident que tout le monde ne doit pas pouvoir utiliser cette commande, il vaut mieux que l'administrateur se réserve ce droit''

'''Ordonnancement équitable.'''

==La mémoire==

===Introduction===

RAM = Random Acces Memory. C'est ce que l'on appelle couramment la mémoire vive, elle peut être modifié à l'infini et sert à stocker temporairement les fichiers que l'ordinateur exécute.

ROM = Read Only Memory. On l'appelle aussi mémoire fixe ou mémoire morte, dès que l'on enregistre, le contenu d'une mémoire ROM ne peut pas être modifié (ex: un CD-ROM).

'''Gestion de la mémoire : '''

Lors du boot du PC, le système est chargé en mémoire.
Tout processus créé est aussi chargé dans la mémoire.

Lorsque l'on créé uns seul processus, il est plus pratique de le charger en "bas" de la mémoire, à partir de la première case de l'espace mémoire. Puis les nouveaux processus peuvent être charger par dessus. Ainsi la machine comprend où commence l'espace mémoire.

Problèmes :
1 - l'espace d'adressage ne commence pas à 0;
2 - un processus peut demander dynamiquement de la mémoire;
3 - avec un accès direct, un processus peut faire "planter" un autre.

==> Il faut avoir une couche d'abstraction au-dessus de la mémoire physique.

===Espaces d'adressage===

Et si l'on créait des espaces d'adressage distincts pour chaque processus ?
Par exemple : chaque processus utilise des adresse de 0 à n de la mémoire, on converti alors ces adresses en adresses physiques.

Certains des premiers processeurs avaient deux registres supérieurs :

- une Base => adresse physique du début de l'espace d'adressage

- une Limite => adresse physique de fin de l'espace d'adressage

Par exemple, lors de l'exécution d'un processus l'accès à une case "a" se transforme en l'accès à la Base+a et un test pour vérifier que : a+Base < Limite.

Malgré tout, ceci ne résout pas les problèmes liés au fait que des processus sont créés et disparaissent, réclament ou libèrent de la mémoire.

===Va-et-vient (swapping)===

====Idée====

Et si pour gérer tout cela on utilisait une mémoire auxiliaire (disque), pour stocker l'état de la mémoire de processus.

La mémoire vue par les processus ne correspond pas à la mémoire physique. À un instant donné, certains processus peuvent se retrouver sur le disque (dans le SWAP).

Quand un processus apparait, on lui cherche un morceau d'espace libre dans la mémoire.

====gestion de la mémoire====

* tableau de bits
* liste chaînée

====Allocation====

* first fit
* next fit
* best fit
* worst fit

===Mémoire virtuelle===

====Idée====

====Pagination====

====Traduction des adresses====

====Table des pages====

====Table inversée====

====Remplacement des pages====

==Les entrées / sorties==

----
----

==Références==

* le livre « Systèmes d'exploitation » de Andrew Tanenbaum est disponible à la BU
* la page du [http://sos.enix.org/fr/PagePrincipale projet SOS]
* la [http://www.opengroup.org/onlinepubs/009695399/nfindex.html norme POSIX:2004]
* l'[http://msdn.microsoft.com/en-us/library/aa383749(VS.85).aspx API win32]
* [http://www.lemis.com/grog/Documentation/Lions/index.php Commentary on the Sixth Edition UNIX Operating System]

INFO502 : Systèmes d'exploitation

2009-11-27T12:19:06Z

Hatat : /* TP */ Sujet TP1

Ce wiki est un complément de cours pour le cours « info-502 : systèmes d'exploitation ». La participation au wiki est fortement encouragée.

Pour pouvoir modifier les pages, inscrivez-vous (lien en haut à droite) pour obtenir un login et mot de passe. (Choisissez un login du style ''PrenomNom''...)

Je vous conseille d'aller lire [http://meta.wikimedia.org/wiki/Aide:Contenu ce guide] pour vous familiariser avec les wikis.

Exercice : si vous n'en avez pas, créez-vous un compte et essayez de modifier cette page (correction de fautes d'hortographe, rajout de détails, mise en page, ...)

Vous pouvez aussi utiliser la page de discussion pour ... discuter. (Ou poser des questions, faire des commentaires etc.)

----
----
==Auteur du cours==

===Nouvelles===

===Supports===

====TD====

Sujets de TD :
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td1.pdf Ordonnancement],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td2.pdf Gestion de la mémoire],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td3.pdf Systèmes de fichiers].

====TP====

# Découverte de SOS
#* [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-tp1.pdf Sujet],
#* [http://www.lama.univ-savoie.fr/~hatat/sos-tp1.tar.gz Code source].

==Introduction==

-- ...

==Repères historiques==

Voici quelques évènements clés dans l'histoire des systèmes d'exploitation. Pour plus de détails, ou pour des compléments sur l'histoire de l'informatique, je vous renvoie sur Wikipedia : [http://en.wikipedia.org/wiki/History_of_operating_systems "History of operating systems"] et [http://en.wikipedia.org/wiki/History_of_computing "History of computing"].

Les premiers ordinateurs ne comportaient pas vraiment de système d'exploitation : c'étaient des opérateurs humains qui géraient tout. (C'était juste après la seconde guerre mondiale, l faut savoir que les langages de programmation n'existaient même pas...) La petite histoire (??) raconte qu'à un moment, les processus pour l'ordinateur de l'université de Cambridge étaient accrochés sur une corde à linge et que c'était la couleur des pinces à linges qui donnait la priorité. (??)

Le passage à la notion de système d'exploitation c'est faite graduellement pour répondre à la complexité de plus en plus grande des ordinateurs et aux demandes des utilisateurs.

Les premier systèmes d'exploitation datent probablement de 1956. Ils permettaient simplement d'exécuter un nouveau programme lorsque le précédent était terminé. Les ordinateurs d'IBM de la famille System/360 ont ensuite eu toute une série de systèmes d'exploitation plus ou moins similaires : OS/360, DOS/360 (rien à voir avec MS-DOS), TSS/360... C'est à cette époque qu'est apparu la notion de multiprogrammation (possibilité d'avoir plusieurs processus entrelacés.)
C'est également au début des années 60 qu'on a commencé à voir des systèmes avec temps partagé : plusieurs utilisateurs pouvaient utiliser un ordinateur. Le système Multics a été, à ce niveau comme à d'autres, assez révolutionnaire. Multics a été utilisé jusqu'en 2000 !

Multics n'était par contre pas approprié pour les mini-ordinateurs où le nombre d'utilisateur est relativement restreint. En 1969, Ken Thomson
a développé une variante simplifié de Multix : Unix...

Ce n'est qu'un peu plus tard (1979) que la première version de DOS (86-DOS ou QDOS) apparaît. 86-DOS sera racheté par Microsoft un 1980...

'''Liens et compléments :'''
* [http://en.wikipedia.org/wiki/Timeline_of_operating_systems Timeline of operating systems]
* généalogie des systèmes Unix : [http://www.levenez.com/unix/ Unix History]
* généalogie de Windows : [http://www.levenez.com/windows/ Windows History]
* généalogie des systèmes non-Unix : [http://www.oshistory.net/metadot/index.pl?id=2165 timeline of non-Unix operating systems]

==Vue d'ensemble==

Ce cours reste assez généraliste et essaie de regarder les principales fonction d'un système d'exploitation. Les systèmes de type Unix (Linux) sera un exemple privilégié. À cause de leur complexité intrinsèque, les évolutions modernes (architectures multicoeur ou multiprocesseur, ...) seront en partie ignorée dans un premier temps.

Les problèmes fins de communication entres processus ne seront que très peu abordés, car ils font l'objet d'un cours séparé (info604) pour la filière info.

Nous allons suivre l'ordre classique consistant à regarder :
# les processus
# la mémoire
# les entrées / sorties

La fin du cours dépendra du temps restant...

===Les processus===

Un processus est simplement un programme « en exécution ». À tout instant, un ordinateur de bureau contemporain contient de nombreux processus qui doivent partager le (les) processeur(s) pour donner l'impression qu'ils s'exécutent « en même temps ». Un des rôles du système d'exploitation consiste à décider dans quel ordre les processus vont effectivement pouvoir utiliser le processus.

===La mémoire===

La mémoire est, comme le processeur, une ressource partagée par les différents processus. Il faut donc gérer la quantité de mémoire allouée et utilisée pour que les processus n'aient pas à s'occuper de ceci. Un des concepts fondamentaux est celui de mémoire virtuelle. Ceci permet d'offrir un espace mémoire pour chacun des processus de manière transparente.

===Les entrées / sorties===

Un ordinateur n'est pas (plus) un système indépendant du reste du monde : il interagit avec l'extérieur à travers des périphériques d'entrées/sorties (clavier / écran / souris / ...). La gestion de ces périphériques pose un ensemble de problèmes que nous aborderons brièvement...

===...===

Une fois ces notions vues, nous regarderons peut-être les problèmes de sécurité, de multimédia ou des architectures multiprocesseurs.

==Préliminaires==

===Quoi ?===

Les ordinateurs, ou plus simplement les micro contrôleurs sont des circuits électroniques avec une puce « processeur ». Le développement d'applications n'est pas facile si on se place au niveau électronique et que l'on parle directement au CPU. Pour faciliter la vie des programmeurs, plusieurs couches d'abstraction sont nécessaires. La première se place au niveau matériel et s'occupe directement des problèmes électroniques ou de très bas niveau. Il s'agit du ''firmware''. Il répond par exemple aux questions comme :
* qu'elle est l'amplitude des signaux envoyés par l'horloge ?
* est-ce que l'UC possède un pipeline ?
* ...
Un firmware est donc forcement très lié au matériel sur lequel il tourne.

La couche suivante est le système d'exploitation à proprement parler. Dans le cas que vous connaissez le mieux (ordinateur personnel), le système d'exploitation fournit une interface pour :
* exécuter un programme
* exécuter plusieurs programmes « en même temps »
* gérer les ressources (temps processeur, mémoire disponible, entrées / sorties)
* les opérations sur les fichiers
* offrir des garanties de sécurité

===Où ?===

On trouve des systèmes d'exploitation partout :

* dans les ordinateurs personnels (Linux, BSD, MacOS, Solaris, Windows, ChromeOS (?))
* dans les PDA (PalmOS, ...)
* dans les téléphones portables (Android, OpenMoko,Symbian,)
* console de jeux
* lecteur MP3 (Rockbox, ...)
* les microcontroleurs « avancés »

===Comment ?===

====Langage de programmation====

Le système d'exploitation se situe entre le firmware (très bas niveau) et l'utilisateur. La nécessité d'accéder à ces ressources de très bas niveau implique que les langages de haut niveaux (Java, Ada, Python, ...) ne sont pas du tout adaptés à l'écriture des systèmes d'exploitation.
Le langage le plus utilisé reste à ce jours le langage C : Linux, BSD, MacOS, Windows, ... sont tous écrits pour leur plus grande partie en C.

Vous avez normalement un cours de C en parallèle, et les TPs utiliseront le langage C. (La référence sur le langage C reste à mon goût le livre de Kernighan et Ritchie : « the C Programming language ». (Disponible en francais à la BU sous le titre « Le langage C : norme Ansi ».) Il existe de nombreux autres livres / documents sur la programmation C comme le [http://www-clips.imag.fr/commun/bernard.cassagne/Introduction_ANSI_C.html polycopié de Bernard Cassagne « introduction au langage C »].

Les premiers systèmes d'exploitation étaient écrits directement en langage machine, ou bien en langage d'assembleur ; et les systèmes actuels comportent encore quelques parties de très bas niveau en langage d'assemblage...

====Notion d'appel système, norme POSIX====

La programmation de haut niveau en C est assez différente de la programmation système. De nombreuses fonctions C utilisent en fait des « appels système », c'est à dire des appels de fonctionnalités propres du système d'exploitation. Les appels système typiques sont :
* les fonctions relatives aux fichiers (création, suppression, modification...)
* les fonctions relatives à la gestion de la mémoire
* les fonctions relatives aux processus (<tt>fork</tt>)
* ...

De nombreux système d'exploitation proposent une interface [http://en.wikipedia.org/wiki/Posix POSIX] (« '''P'''ortable '''O'''perating '''S'''ystem '''I'''nterface for Uni'''x''' »). Cette norme définit entre autres un ensemble de fonctions pour utiliser les appels systèmes.
Le nombre de ces fonctions est relativement faible : une centaine ; et chacune correspond en gros à un appel système. Certaines de ces fonctions ne sont pas définies directement dans le système d'exploitation, mais dans des librairies. Pour Linux, il s'agit en général de la librairie Glibc (GNU C Library).

Par exemple, la fonction <tt>open</tt> (qui permet d'ouvrir un fichier) correspond exactement à un appel système ; alors que la fonction <tt>malloc</tt> (qui permet d'allouer dynamiquement de la mémoire dans le tas) peut générer plusieurs appels système (<tt>brk</tt> et <tt>sbrk</tt>).

Pour visualiser les appels systèmes effectués par un programme sous Linux, vous pouvez utilisez l'utilitaire <tt>strace</tt> ou <tt>ltrace</tt>. Par exemple, dans le shell :
$ strace -e trace=file ls -l 2> trace
permet de récupérer tous les appels systèmes relatifs aux fichiers lors de l'appel à <tt>ls -l</tt>. La liste des appels système est redirigée dans le fichier <tt>trace</tt> qui contiendra par exemple des lignes telles que
lstat64("Desktop", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lgetxattr("Desktop", "security.selinux", 0x8cc08e0, 255) = -1 ENODATA (No data available)
dénotant ainsi un appel aux appels système <tt>lstat64</tt> et <tt>lgetxattr</tt>...

Les principaux systèmes compatibles POSIX sont :
* Linux
* BSD (et variantes)
* Mac OS X
* Solaris

De nombreux appels systèmes sont disponibles directement (sans avoir besoin d'écrire un programme C) à travers le shell. Exécuté dans un terminal, le shell permet, en première approximation, de passer directement des commandes au système d'exploitation. (La norme POSIX définit également un ensemble de fonctions du shell. Il est donc relativement aisé de changer de système d'exploitation tant qu'on reste dans les systèmes compatibles POSIX.)

Windows d'un autre côté utilise l'interface Win32 API, qui définit plusieurs milliers de fonctions. La plupart de ces fonctions peuvent utiliser plusieurs appels système...

Les systèmes d'exploitation qui utilisent l'API Win32 sont :
* Windows, depuis Windows95.

Il est possible d'installer un environnement compatible POSIX sur une machine Windows grâce à Cygwin. (C'est d'ailleurs fortement conseillé si vous ne voulez pas installer une version de Linux ou BSD sur votre ordinateur personnel...)

====Mode noyau / mode utilisateur====

La partie fondamentale du système d'exploitation est le ''noyau'' (''kernel'' en anglais). C'est la couche de plus bas niveau.

Les fonctionnalités de très bas niveau offertes par le noyau peuvent facilement planter l'ordinateur. Il faut donc une politique de restriction pour que tous les programmes ne puissent y accéder dans leur totalité. On parle de
* mode noyau
* mode utilisateur

Dans le mode utilisateur, on ne peut accéder à ces fonctionnalités qu'a travers les appels systèmes ; dans le mode noyau, on peut tout faire... Bien entendu, un appel système doit passer momentanément en mode noyau pour pouvoir exécuter les commandes pertinentes, puis il repasse automatiquement en mode utilisateur.

La définition d'un appel système pourrait donc être « fonctionnalité atomique nécessitant un passage en mode noyau ».

====Noyau, noyau monolithique, micro-noyau====

La partie principale du système d'exploitation. C'est lui qui gère les ressources, les entrées / sorties, la communication entre processus, ... Les deux architectures principales pour un noyau sont :
* noyau monolithique
* micro-noyau
La plupart des systèmes actuels sont basés sur un noyau monolithique (Linux, BSD, Mac OS X, Solaris, Windows).

Les noyaux monolithiques sont parfois décrits comme « sans vraie structure » : une grosse soupe où cohabitent toutes les fonctionnalités du système d'exploitation. L'idée d'avoir un système unique qui gère tout est effectivement peu attirante et peut poser quelques problèmes de génie logiciel...
Un noyau monolithique est donc la couche entre le matériel et les programmes utilisateurs. Pour éviter de compiler des noyaux énormes, les noyaux monolithiques actuels utilisent en plus la notion de ''module''. Ce sont des morceaux du noyau qu'on peut charger ou décharger au besoin. Si l'interface est connue, ces modules peuvent éventuellement être en binaire, ce qui permet d'utiliser des modules propriétaires avec un noyau libre.
Sous Linux, la commande
$ lsmod
permet d'obtenir la liste des modules chargés dans le noyau.

Les micro-noyaux d'un autre coté sont basés sur la remarque que seule une toute petite partie du noyau accède effectivement au matériel. Seule cette petite partie nécessite donc des privilèges et effectue des appels système. Le reste du système d'exploitation peut être programmé en mode utilisateur, « au dessus » de cette partie. Par exemple, le micro noyau offrira la possibilité de charger un nouveau processus, mais l'ordonnanceur (qui choisit quel processus devra être chargé) ne fera pas partie du micro-noyau. On parle parfois de ''services'' / ''serveurs'' au dessus du micro-noyau.
Ceci permet d'avoir un noyau bas niveau beaucoup plus petit. Bien que ceci soit une bonne idée, et que les micro-noyaux puissent fournir de meilleurs garanties de sécurité, peu de noyaux sont effectivement des micro-noyaux. Un des problèmes est qu'un tel micro-noyau est un peu plus lent que ses cousins monolithiques. La raison principale est que dans le cas d'un micro-noyau, un appel système nécessite en fait des communications inter-processus.
Andrew Tanenbaum est un fervent défenseur des micro-noyaux.

Une autre architecture possible est d'utiliser des couches successives, chacune avec des privilèges réduits. Le système Multics avait cette architecture.
Par exemple, dans le système THE (1965), les couches étaient les suivantes :
# noyau bas niveau, multiprogrammation
# allocation de la mémoire pour les processus
# IPC (communication inter processus)
# entrées / sorties (buffer, etc.)
# programmes utilisateurs (compilation, exécution, ...)
# utilisateur (Dijkstra a annoté la description de cette couche par ''« not implemented by us »'')

Une dernière catégorie de noyau est la catégorie des machines virtuelles. Ces noyaux sont un peu à part, car il s'agit d'émuler un système d'exploitation ou du matériel particulier à l'intérieur d'un autre système d'exploitation ou matériel. Le mode noyau de la machine virtuelle est en fait dans le mode utilisateur du noyau original...

==Les processus==

===Introduction===

Allez hop commençons par une petite définition du type wikipédia :

Un processus (en anglais, process), en informatique, est défini par :
* un ensemble d'instructions à exécuter (un programme) ;
* un espace mémoire pour les données de travail ;
* éventuellement, d'autres ressources, comme des descripteurs de fichiers, des ports réseau, etc.

Un ordinateur équipé d'un système d'exploitation à temps partagé est capable d'exécuter plusieurs processus de façon « quasi- simultanée ». Par analogie avec les télécommunications, on nomme multiplexage (A. Tanenbaum parle de ''multiprogrammation'') ce procédé. S'il y a plusieurs processeurs, le système essaie de répartir les processus de manière équitable sur les processeurs disponibles.

Le processus doit être imaginé comme quelque chose qui prend du temps, donc qui a un début et (parfois) une fin. De nombreux processus ne se terminent normalement jamais : système d'exploitation, serveurs web, serveurs mail, ... D'autres processus plus légers qui ne se terminent pas sont les ''daemon'' (acronyme ''a posteriori'' de "disk and execution monitor") du monde Unix.

Certains processus sont démarrés très tôt lors de la séquence de boot. Le système d'exploitation est un tel processus. Sinon, les processus sont normalement démarrés grâce à un appel système à partir d'un autre processus. L'utilisateur peut par exemple demander explicitement un nouveau processus (sous POSIX, grâce à un <tt>fork</tt> puis <tt>exec</tt>) ; mais la plupart du temps, il le fera à travers une application, par exemple en double-cliquant sur l'icône d'un programme dans l'explorateur de fichiers.

Le système d'exploitation est chargé d'allouer les ressources (mémoires, temps processeur, entrées/sorties) nécessaires aux processus et d'assurer que le fonctionnement d'un processus n'interfère pas avec celui des autres (isolation).

Pas sûr d'avoir tout compris ? Ce n'est pas grave, essayons autrement.
:'''Définition :''' un processus est un programme en train de s'exécuter.
Cette définition implique en particulier que un programme (navigateur Firefox par exemple) peut correspondre à
* zéro processus si on ne l'a pas lancé,
* un processus si on l'a lancé,
* plusieurs processus si on l'a lancé plusieurs fois.
(''Remarque :'' pour un programme comme Firefox, il y a fort à parier que l'exécution d'une seule instance de Firefox génère de multiples sous-processus...)

Que se passe-t-il quand je démarre une application?

:L'ordinateur à une nouvelle tâche à accomplir, les instructions correspondantes sont donc envoyées au processeur. Comme il a plusieurs choses à faire le choix des instructions à exécuter n'est pas forcement simple. Il faut faire en sorte de partager le processeur entre les différentes tâches de manière équitable : c'est la fameuse gestion des processus.
:Ceci permet de réaliser plusieurs activités en ~même temps~. Grâce à la gestion des processus on peut regarder un film (obtenu par des moyens tout à fait légaux cela va de soit), tout en jouant à la dame de pique.
:(et dire que certain(e)s affirment que l'homme est mono tâche)

Plusieurs processus indépendants peuvent être ''actifs'' en même temps, mais sauf si l'ordinateur possède suffisamment de processeurs, on ne peut pas les exécuter simultanément. L'impression que plusieurs programmes s'exécutent ''en même temps'' vient simplement du fait que le processeur alterne rapidement entre eux.
Comme le temps d'exécution d'une instruction par le processeur est très court, de l'ordre de la nano-seconde, le processeur peut réaliser plusieurs centaines de millions d'instructions par seconde. Ainsi, une tranche de temps de quelques fractions de seconde, partagée entre plusieurs processus, donne à l'échelle macroscopique l'illusion de la simultanéité.

'''En résumé :''' un système d'exploitation doit la plupart du temps traiter plusieurs tâches en même temps, et comme il n'a, en général, qu'un seul processeur, il devra contourner ce problème grâce à un pseudo-parallélisme. Il traite une tâche à la fois, s'interrompt et passe à la suivante. La commutation de tâches étant très rapide, il donne l'illusion d'effectuer un traitement simultané.

===La table des processus===

L'information sur les processus est conservé par le système dans une structure de données appelée ''table des processus''. Cette table contient toutes les informations nécessaires à la gestion des processus :
* état du processus
* PID
* droits
* répertoire de travail
* pointeur vers la pile
* priorités
* ...

Sous Linux, on peut accéder à ces informations à travers le système de fichiers virtuel "Procfs". Il suffit d'aller dans le répertoire <tt>/proc/</tt>.

===Création d'un processus===

Pour les système POSIX, la création d'un processus est très simple : on utilise la fonction <tt>fork()</tt>. En C, le prototype de la fonction se trouve dans le fichier d'entêtes <tt>unistd.h</tt>.

Cette fonction prend 0 argument et permet de faire la chose suivante : elle crée un nouveau processus qui est une copie conforme du processus appelant. La seule différence visible entre l'ancien et le nouveau processus est que les processus ont un numéro (PID) différent. Pour le processus appelant, il peut obtenir le PID du nouveau processus en regardant la valeur de retour de <tt>fork</tt>. Pour le nouveau processus, cette valeur vaudra 0, et il devra utiliser la fonction <tt>getpid()</tt> pour obtenir son numéro.

Le processus appelant est appelé le ''père'' alors que le nouveau processus est appelé le ''fils''.

Notez que l'espace mémoire du processus est dupliqué plutôt que partagé. Ceci veut dire que les processus ne peuvent pas communiquer en utilisant leur variables... Par contre, les descripteurs de fichiers du fils sont hérités directement de ceux du père ; ils peuvent donc essayer de communiquer en passant par ces fichiers. (Mais cela pose de nombreux problèmes de synchronisation.)

Voici par exemple un petit programme C qui lance un processus fils:
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {

int pid ;
int pid_fils ;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
} else {
printf(" >> Je suis le fils.\n");
}

return(0);

}
Après compilation, voici un exemple d'exécution du programme résultant :
$ ./pere_fils
> Le processus 8248 démarre...
>> Je suis le fils.
>> Je suis le père (pid du fils = 8249).

Voici un autre exemple d'exécution :
$ ./pere_fils
> Le processus 8269 démarre...
>> Je suis le père (pid du fils = 8270).
>> Je suis le fils.

Notez que les numéros sont différents, et que l'ordre d'affichage n'est pas le même. Cela vient de l'ordonnancement des deux processus qui peut différer.

La technique consistant à faire
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
...
}
montre que malgré le fait que les processus soient identiques à l'origine, on peut faire beaucoup de chose.

:'''Remarque :''' <tt>fork()</tt> n'est pas directement un appel système, mais une fonction qui utilise l'appel système <tt>clone()</tt>. Cet appel système ne fait pas partie de la norme POSIX...

La deuxième technique utilisée dans les systèmes POSIX consiste à utiliser <tt>fork()</tt> pour dupliquer le processus, puis à complètement remplacer le fils par un nouveau processus. La fonction correspondante est la fonction <tt>execv</tt> :
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
execv("/usr/bin/...", argv);
...
}
La fonction <tt>execv</tt> prend 2 arguments : une chaîne contenant le chemin d'accès à un programme, et un tableau d'arguments à donner au programme. (C'est un peu plus compliqué que ça : le premier élément du tableau est le nom du programme, et le tableau doit se terminer par un pointeur NULL.)

Une dernière fonction importante est la fonction <tt>wait(pid)</tt> qui permet à un processus d'attendre l'arrêt du processus <tt>pid</tt>.

-- ...

L'API WIN32 possède de nombreuses fonctions avec des fonctionnalités similaires. Par exemple, la fonction [http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx <tt>CreateProcess</tt>] permet de créer un nouveau processus (comme un <tt>fork</tt> suivi d'un <tt>exec</tt>), mais elle nécessite ... 10 arguments !

----

Un autre moyen de créer des processus est d'utiliser des 'processus légers' appelés Thread. Ces processus légers partage seulement une partie de la mémoire, ce qui en pratique est plus rapide pour simuler un parallélisme. On passe alors par une autre fonction. Sous GNU/Linux, lors de l'écriture d'un programme écrit en C il faut utiliser la bibliothèque pthread.h et lors de la compilation, faire un lien vers celle ci, en utilisant le paramètre -lpthread.

====Arborescence des processus dans les systèmes POSIX====

Nous avons vu que la fonction <tt>fork()</tt> permet de créer un processus fils. Le père connaît le PID de son fils : il lui est donné par la fonction <tt>fork()</tt>. Comme le fils peut lui même créer des processus fils, on obtient rapidement une arborescence de processus.

Vous pouvez visualiser cette arborescence à partir d'un terminal avec la commande <tt>pstree</tt> (l'option <tt>-p</tt> permet de demander l'affichage des PID)
$ pstree -p
init(1)─┬─acpid(25425)
├─atd(14365)
├─console-kit-dae(3632)─┬─{console-kit-dae}(3633)
│ ├─{console-kit-dae}(3641)
...
├─cron(14315)
├─dbus-daemon(15590)
├─dbus-daemon(3511)
...
├─getty(4095)
├─getty(4096)
├─getty(4097)
├─getty(4098)
├─getty(4099)
├─gpm(3528)
...
├─kded4(15769)
├─kdeinit4(15766)───klauncher(15767)
├─kdm(15564)─┬─Xorg(15566)
│ └─kdm(15573)───sh(15608)─┬─conky(15751)
│ ├─fluxbox(15703)───firefox-bin(6063)─┬─{firefox-bin}(6064)
│ │ ├─{firefox-bin}(6065)
...
│ ├─ssh-agent(15698)
│ ├─unclutter(15742)
│ ├─wicd-client(15749)
│ └─xscreensaver(15683)
...
├─rsyslogd(6850)─┬─{rsyslogd}(6140)
│ └─{rsyslogd}(6141)
├─screen(4427)─┬─bash(4428)───pstree(9307)
│ ├─bash(4429)───man(7952)───pager(7965)
│ ├─bash(4430)───vi(30568)
│ ├─bash(18395)───vi(28512)
│ └─mutt(8763)
...

Le processus <tt>init</tt> est l'ancêtre de tout les processus, il a toujours 1 comme PID.

'''Remarque :''' sous Windows, les processus ne sont pas organisé en arborescence...

====Mort d'un processus dans un système POSIX====

Un processus peut se terminer pour plusieurs raisons :
* volontairement, grâce à la fonction <tt>exit()</tt> (POSIX) ou <tt>ExitProcess()</tt> (Windows),
* à cause d'une erreur,
* en recevant un signal d'un autre processus, grâce à la fonction <tt>kill()</tt> (POSIX) ou <tt>TerminateProcess()</tt> (Windows).

Lorsqu'un processus se termine, plusieurs choix sont possibles :
* que fait-on de ses fils ?
* que fait-on de son père ?

Linux fait la chose suivante : quand un processus s'arrête,
* tous ces fils s'arrêtent,
* son père reçoit un signal le prévenant que son fils vient de mourir.

Pour que le père puisse recevoir le signal correspondant, il faut qu'il utilise la fonction <tt>wait()</tt> ou <tt>waitpid()</tt>. Tant que le parent existe et qu'il n'a pas reçu le signal disant qu'un de ces fils est mort, le processus fils n'est pas entièrement supprimé : il devient un ''zombie''. (Il n'occupe plus vraiment de place en mémoire, mais le système garde juste suffisamment d'information pour pouvoir prévenir le père si celui ci demande l'état du fils.)

'''Remarque :''' les processus Windows ne sont pas organisés sous forme d'arborescence. Chaque processus peut surveiller l'état d'un autre processus, s'il connaît son PID. Il n'y a donc pas de notion de processus ''zombie'' sous Windows.

Voici un petit programme C qui crée un processus fils, ne fait rien pendant 20 secondes, puis demande l'état de son fils :
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
int pid ;
int pid_fils ;
int w;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
printf(" >> Je suis le père et j'attends un peu.\n");
sleep(20);
printf(" >> Je suis le père et je demande l'état de mon fils.\n");
wait(&w);
printf(" >> Mon fils est mort (signal %i).\n", w);
while(1) sleep(1);
} else {
printf(" >> Je suis le fils.\n");
while (1) sleep(1);
exit(0);
}
return(0);
}
Si on tue le processus fils pendant que le père ne fait rien, le processus fils devient un zombie. Dès que le père fait le <tt>wait</tt>, il reçoit la valeur du signal qui a terminé le processus et le zombie disparaît.

Si on ne tue pas le processus fils, le père n'exécutera jamais le <tt>printf(" >> Mon fils est mort...);</tt>.

'''Remarque :''' dans un système POSIX, lorsqu'un processus meurt, ses fils deviennent ''orphelins''. Il continuent leur exécution mais sont adopté par <tt>init</tt> (PID : 1). Dans certains cas lorsque le processus est arrêté, il envoie explicitement un signal <tt>SIGTERM</tt> pour tuer ses processus fils. C'est par exemple ce qui arrive lorsqu'on lance des application à partir d'un terminal et que l'on quitte le terminal en question...

===États d'un processus===

On peut imaginer un SE dans lequel les processus pourraient être dans trois états :
* en cours d'exécution,
*bloqué : il attend un événement extérieur pour pouvoir continuer (par exemple une ressource; lorsque la ressource est disponible, il passe à l'état "prêt")
*prêt : suspendu provisoirement pour permettre l'exécution d'un autre processus.

Dans un système avec un unique processeur, au plus un processus peut se trouver dans l'état ''en cours d'exécution''. Par contre, il peut y avoir de nombreux processus dans l'état ''bloqué'' ou dans l'état ''prêt''.

Un processus peut passer d'un état à l'autre :
# de ''en exécution'' à ''bloqué'' lorsqu'une ressource n'est pas disponible (entrées / sortie par exemple),
# de ''bloqué'' à ''prêt'' si la ressource ayant provoqué le blocage devient disponible,
# de ''en exécution'' à ''prêt'' si le système décide de suspendre l'exécution du processus,
# de ''prêt'' à ''en exécution'' si le système décide de lancer l'exécution du processus.

On peut résumer ceci par le graphe de transitions suivant :

[[Image:Diagrammedétatdunprocessus.png]]

Les transition manquantes ne sont pas possible directement mais doivent passer par des transition intermédiaires.

On peut ajouter 2 états :
* ''nouveau'' pour un processus qui vient d'être créé,
* ''terminé'' pour un processus qui vient de se terminé.

Dans les systèmes type ''ordinateur de bureau'', le passage de ''nouveau'' à ''prêt'' est automatique mais dans des systèmes temps réel, un processus peut parfois attendre dans cet état.

L'état ''terminé'' est en général passager. Par exemple, lorsqu'un processus terminé est un zombie, le processus n'est conservé que dans la table des processus. La mémoire utilisé par le processus est libérée. La question de savoir si ceci est véritablement un état du processus est donc essentiellement une question de vocabulaire.

:exercice : ajouter les états ''nouveau'' et ''terminé'' et les transitions correspondantes au graphe précédent. Identifiez des situations provoquant les transitions possibles entre états.

===Ordonnancement des processus===

Nous avons vu qu'il pouvait y avoir de nombreux processus dans la table de processus (environ 150 sur mon ordinateur en ce moment même). Parmi ces processus, un seul (sur une machine à un processeur) peut se trouver dans l'état ''en exécution''. C'est au système d'exploitation de décider qui, à un moment donnée, doit se trouver dans cet état. La partie du système faisant ceci s'appelle ''ordonnanceur'' (ou ''scheduler'' en anglais).
En utilisant le contenu de la table des processus et éventuellement d'autres information, ordonnanceur doit donc gérer les transition entre états de tous les processus, et envoyer l'information nécessaire aux composants adéquat du noyau.

Comme d'habitude, l'ordonnanceur doit faire des compromis entre :
* la vitesse,
* l'utilisation de la mémoire,
* l'optimalité de la solution proposée.

'''Remarque : ''' l'ordonnanceur est lui même un processus (ou un morceau de processus dans le cas des noyaux monolithiques).

====Ordonnancement non préemptif====

'''FIFO.'''
L'algorithme d'ordonnancement le plus facile est probablement celui de type ''FIFO'' : premier arrivé, premier servi. Autrement dit, on préempte premier processus arrivé, et on l'exécute jusqu'à la fin. La seul structure de donnée est donc simplement une ''file''.

'''Plus court temps d'exécution.'''
Dans certain cas, on peut prévoir a l'avance le temps processeur dont aura besoin un processus pour s'exécuter. On peut alors choisir le processus le plus court et l'exécuter en premier. Ceci a en général tendance à diminuer le temps d'attente moyen d'un processus ; mais si des processus courts sont crées régulièrement, on peut assister à une ''famine'' : un processus peut ne jamais s'exécuter.

:exercice : trouver une suite de processus qui provoque une famine.

Ces deux exemples sont acceptables pour un ''traitement par lots'' (batch) par exemple pour des calculs numériques. Ils ne sont par contre pas du tout adaptés pour un ordinateur personnel ou un système temps réels. (Pas de ''multiprogrammation''.)

====Ordonnancement préemptif====

Pour pouvoir donner l'illusion de simultanéité, les processus sont en général exécutés par tranches de temps spécifiées à l'avance (''time slice'' en anglais). Au bout de ce temps, le noyau reçoit une interruption et examine les processus. Il peut décider de continuer le processus courant, ou bien le remplacer par un autre processus. on parle de préemption.

Windows 3.1 ou MacOS 9 étaient des systèmes ''collaboratifs'' car les processus devaient explicitement laisser la main aux autres processus. Tous les systèmes d'exploitation modernes sont maintenant préemptifs. On parle maintenant de système préemptif lorsque la préemption peut s'effectuer même sur des processus en mode noyau.
On parle parfois de noyau préemptible lorsque que les opérations en mode noyau sont elle même préemptibles.

'''Tourniquet.'''
L'algorithme le plus simple est probablement celui du tourniquet (''round Robin'' en anglais). C'est une variante de l'algorithme FIFO vu plus haut, mais qui préempte le processus courant au bout d'un moment. Si ce processus est encore en exécution, on le remet à la fin de la file des processus.

Le temps imparti à chaque processus ne doit pas être trop court (sinon, le changement de contexte prend trop de temps par rapport à l'exécution des processus) ni trop long (sinon, on perd l'illusion de parallélisme, et un processus bloqué risque d'occuper le processeur pendant trop longtemps).

Voici ce qu'on peut trouver dans le livre "Understanding the Linux kernel" :

<cite>
The choice of quantum duration is always a compromise. The rule of thumb adopted by Linux is: choose a duration as long as possible, while keeping good system response time.
</cite>

(extrait du chapitre [http://oreilly.com/catalog/linuxkernel/chapter/ch10.html "Process Scheduling"]).

'''Tourniquet avec priorité.'''
Tous les processus ne naissent pas égaux : certains ont une importance plus élevée (les processus systèmes par exemple). Dans un cas comme le précédent, tous les processus ont le même statut...
Pour corriger ce problème, on utilise parfois un algorithme similaire, mais on choisit le premier processus de priorité la plus élevé possible. Plutôt que de parcourir la file à sa rechercher, on utilise en fait plusieurs files : une pour chaque priorité.

Il faut faire attention car les processus de priorité basse risquent de ne jamais être exécutés (famine)... Par exemple, on peut diminuer petit à petit la priorité des processus qu'on exécute...

Une autre solution pour gérer les priorité en évitant certaines famines est d'exécuter toutes les files, mais pas en proportion égale. Par exemple, on choisit un processus dans les piles de priorité 1, 2, 1, 3, 1, 2, 1, 4, 1, 2, 1, 3, 1, 2, 1, ... De cette manière, les processus de la première file sont exécutés 2 fois plus de fois que ceux de la file 2, et 4 fois plus de fois que ceux de la file 3.

:exercice : donnez un algorithme pour générer la suite précédente pour un nombre donné de files. Il faut que la file ''i'' soit utilisée 2 fois plus souvent que la pile ''i+1''.

'''Répartition garantie.'''
Chaque tache reçoit la même proportion du processeur, et chaque utilisateur reçoit la même proportion également.

'''tirage aléatoire.'''
À chaque étape, on tire un "billet" au hasard, et le processus qui a le "billet gagnant" s'exécute.

Principe de priorité : Les processus qui ont été définit comme prioritaire on plus de "billet" à leur nom et ont donc plus de chance d'être tiré.

''NB : POSIX définit une commande "nice" qui permet e donner à un processus un priorité plus faible (et par conséquent, nice -x augmente cette priorité). Il est évident que tout le monde ne doit pas pouvoir utiliser cette commande, il vaut mieux que l'administrateur se réserve ce droit''

'''Ordonnancement équitable.'''

==La mémoire==

===Introduction===

RAM = Random Acces Memory. C'est ce que l'on appelle couramment la mémoire vive, elle peut être modifié à l'infini et sert à stocker temporairement les fichiers que l'ordinateur exécute.

ROM = Read Only Memory. On l'appelle aussi mémoire fixe ou mémoire morte, dès que l'on enregistre, le contenu d'une mémoire ROM ne peut pas être modifié (ex: un CD-ROM).

'''Gestion de la mémoire : '''

Lors du boot du PC, le système est chargé en mémoire.
Tout processus créé est aussi chargé dans la mémoire.

Lorsque l'on créé uns seul processus, il est plus pratique de le charger en "bas" de la mémoire, à partir de la première case de l'espace mémoire. Puis les nouveaux processus peuvent être charger par dessus. Ainsi la machine comprend où commence l'espace mémoire.

Problèmes :
1 - l'espace d'adressage ne commence pas à 0;
2 - un processus peut demander dynamiquement de la mémoire;
3 - avec un accès direct, un processus peut faire "planter" un autre.

==> Il faut avoir une couche d'abstraction au-dessus de la mémoire physique.

===Espaces d'adressage===

Et si l'on créait des espaces d'adressage distincts pour chaque processus ?
Par exemple : chaque processus utilise des adresse de 0 à n de la mémoire, on converti alors ces adresses en adresses physiques.

Certains des premiers processeurs avaient deux registres supérieurs :

- une Base => adresse physique du début de l'espace d'adressage

- une Limite => adresse physique de fin de l'espace d'adressage

Par exemple, lors de l'exécution d'un processus l'accès à une case "a" se transforme en l'accès à la Base+a et un test pour vérifier que : a+Base < Limite.

Malgré tout, ceci ne résout pas les problèmes liés au fait que des processus sont créés et disparaissent, réclament ou libèrent de la mémoire.

===Va-et-vient (swapping)===

====Idée====

Et si pour gérer tout cela on utilisait une mémoire auxiliaire (disque), pour stocker l'état de la mémoire de processus.

La mémoire vue par les processus ne correspond pas à la mémoire physique. À un instant donné, certains processus peuvent se retrouver sur le disque (dans le SWAP).

Quand un processus apparait, on lui cherche un morceau d'espace libre dans la mémoire.

====gestion de la mémoire====

* tableau de bits
* liste chaînée

====Allocation====

* first fit
* next fit
* best fit
* worst fit

===Mémoire virtuelle===

====Idée====

====Pagination====

====Traduction des adresses====

====Table des pages====

====Table inversée====

====Remplacement des pages====

==Les entrées / sorties==

----
----

==Références==

* le livre « Systèmes d'exploitation » de Andrew Tanenbaum est disponible à la BU
* la page du [http://sos.enix.org/fr/PagePrincipale projet SOS]
* la [http://www.opengroup.org/onlinepubs/009695399/nfindex.html norme POSIX:2004]
* l'[http://msdn.microsoft.com/en-us/library/aa383749(VS.85).aspx API win32]
* [http://www.lemis.com/grog/Documentation/Lions/index.php Commentary on the Sixth Edition UNIX Operating System]

INFO502 : Systèmes d'exploitation

2009-11-17T16:10:45Z

Hatat : /* TD */ Liens vers les sujets

Ce wiki est un complément de cours pour le cours « info-502 : systèmes d'exploitation ». La participation au wiki est fortement encouragée.

Pour pouvoir modifier les pages, inscrivez-vous (lien en haut à droite) pour obtenir un login et mot de passe. (Choisissez un login du style ''PrenomNom''...)

Je vous conseille d'aller lire [http://meta.wikimedia.org/wiki/Aide:Contenu ce guide] pour vous familiariser avec les wikis.

Exercice : si vous n'en avez pas, créez-vous un compte et essayez de modifier cette page (correction de fautes d'hortographe, rajout de détails, mise en page, ...)

Vous pouvez aussi utiliser la page de discussion pour ... discuter. (Ou poser des questions, faire des commentaires etc.)

----
----
==Auteur du cours==

===Nouvelles===

===Supports===

====TD====

Sujets de TD :
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td1.pdf Ordonnancement],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td2.pdf Gestion de la mémoire],
# [http://www.lama.univ-savoie.fr/~hatat/cours/2009-info502-td3.pdf Systèmes de fichiers].

====TP====

----
----

==Introduction==

-- ...

==Repères historiques==

Voici quelques évènements clés dans l'histoire des systèmes d'exploitation. Pour plus de détails, ou pour des compléments sur l'histoire de l'informatique, je vous renvoie sur Wikipedia : [http://en.wikipedia.org/wiki/History_of_operating_systems "History of operating systems"] et [http://en.wikipedia.org/wiki/History_of_computing "History of computing"].

Les premiers ordinateurs ne comportaient pas vraiment de système d'exploitation : c'étaient des opérateurs humains qui géraient tout. (C'était juste après la seconde guerre mondiale, l faut savoir que les langages de programmation n'existaient même pas...) La petite histoire (??) raconte qu'à un moment, les processus pour l'ordinateur de l'université de Cambridge étaient accrochés sur une corde à linge et que c'était la couleur des pinces à linges qui donnait la priorité. (??)

Le passage à la notion de système d'exploitation c'est faite graduellement pour répondre à la complexité de plus en plus grande des ordinateurs et aux demandes des utilisateurs.

Les premier systèmes d'exploitation datent probablement de 1956. Ils permettaient simplement d'exécuter un nouveau programme lorsque le précédent était terminé. Les ordinateurs d'IBM de la famille System/360 ont ensuite eu toute une série de systèmes d'exploitation plus ou moins similaires : OS/360, DOS/360 (rien à voir avec MS-DOS), TSS/360... C'est à cette époque qu'est apparu la notion de multiprogrammation (possibilité d'avoir plusieurs processus entrelacés.)
C'est également au début des années 60 qu'on a commencé à voir des systèmes avec temps partagé : plusieurs utilisateurs pouvaient utiliser un ordinateur. Le système Multics a été, à ce niveau comme à d'autres, assez révolutionnaire. Multics a été utilisé jusqu'en 2000 !

Multics n'était par contre pas approprié pour les mini-ordinateurs où le nombre d'utilisateur est relativement restreint. En 1969, Ken Thomson
a développé une variante simplifié de Multix : Unix...

Ce n'est qu'un peu plus tard (1979) que la première version de DOS (86-DOS ou QDOS) apparaît. 86-DOS sera racheté par Microsoft un 1980...

'''Liens et compléments :'''
* [http://en.wikipedia.org/wiki/Timeline_of_operating_systems Timeline of operating systems]
* généalogie des systèmes Unix : [http://www.levenez.com/unix/ Unix History]
* généalogie de Windows : [http://www.levenez.com/windows/ Windows History]
* généalogie des systèmes non-Unix : [http://www.oshistory.net/metadot/index.pl?id=2165 timeline of non-Unix operating systems]

==Vue d'ensemble==

Ce cours reste assez généraliste et essaie de regarder les principales fonction d'un système d'exploitation. Les systèmes de type Unix (Linux) sera un exemple privilégié. À cause de leur complexité intrinsèque, les évolutions modernes (architectures multicoeur ou multiprocesseur, ...) seront en partie ignorée dans un premier temps.

Les problèmes fins de communication entres processus ne seront que très peu abordés, car ils font l'objet d'un cours séparé (info604) pour la filière info.

Nous allons suivre l'ordre classique consistant à regarder :
# les processus
# la mémoire
# les entrées / sorties

La fin du cours dépendra du temps restant...

===Les processus===

Un processus est simplement un programme « en exécution ». À tout instant, un ordinateur de bureau contemporain contient de nombreux processus qui doivent partager le (les) processeur(s) pour donner l'impression qu'ils s'exécutent « en même temps ». Un des rôles du système d'exploitation consiste à décider dans quel ordre les processus vont effectivement pouvoir utiliser le processus.

===La mémoire===

La mémoire est, comme le processeur, une ressource partagée par les différents processus. Il faut donc gérer la quantité de mémoire allouée et utilisée pour que les processus n'aient pas à s'occuper de ceci. Un des concepts fondamentaux est celui de mémoire virtuelle. Ceci permet d'offrir un espace mémoire pour chacun des processus de manière transparente.

===Les entrées / sorties===

Un ordinateur n'est pas (plus) un système indépendant du reste du monde : il interagit avec l'extérieur à travers des périphériques d'entrées/sorties (clavier / écran / souris / ...). La gestion de ces périphériques pose un ensemble de problèmes que nous aborderons brièvement...

===...===

Une fois ces notions vues, nous regarderons peut-être les problèmes de sécurité, de multimédia ou des architectures multiprocesseurs.

==Préliminaires==

===Quoi ?===

Les ordinateurs, ou plus simplement les micro contrôleurs sont des circuits électroniques avec une puce « processeur ». Le développement d'applications n'est pas facile si on se place au niveau électronique et que l'on parle directement au CPU. Pour faciliter la vie des programmeurs, plusieurs couches d'abstraction sont nécessaires. La première se place au niveau matériel et s'occupe directement des problèmes électroniques ou de très bas niveau. Il s'agit du ''firmware''. Il répond par exemple aux questions comme :
* qu'elle est l'amplitude des signaux envoyés par l'horloge ?
* est-ce que l'UC possède un pipeline ?
* ...
Un firmware est donc forcement très lié au matériel sur lequel il tourne.

La couche suivante est le système d'exploitation à proprement parler. Dans le cas que vous connaissez le mieux (ordinateur personnel), le système d'exploitation fournit une interface pour :
* exécuter un programme
* exécuter plusieurs programmes « en même temps »
* gérer les ressources (temps processeur, mémoire disponible, entrées / sorties)
* les opérations sur les fichiers
* offrir des garanties de sécurité

===Où ?===

On trouve des systèmes d'exploitation partout :

* dans les ordinateurs personnels (Linux, BSD, MacOS, Solaris, Windows, ChromeOS (?))
* dans les PDA (PalmOS, ...)
* dans les téléphones portables (Android, OpenMoko,Symbian,)
* console de jeux
* lecteur MP3 (Rockbox, ...)
* les microcontroleurs « avancés »

===Comment ?===

====Langage de programmation====

Le système d'exploitation se situe entre le firmware (très bas niveau) et l'utilisateur. La nécessité d'accéder à ces ressources de très bas niveau implique que les langages de haut niveaux (Java, Ada, Python, ...) ne sont pas du tout adaptés à l'écriture des systèmes d'exploitation.
Le langage le plus utilisé reste à ce jours le langage C : Linux, BSD, MacOS, Windows, ... sont tous écrits pour leur plus grande partie en C.

Vous avez normalement un cours de C en parallèle, et les TPs utiliseront le langage C. (La référence sur le langage C reste à mon goût le livre de Kernighan et Ritchie : « the C Programming language ». (Disponible en francais à la BU sous le titre « Le langage C : norme Ansi ».) Il existe de nombreux autres livres / documents sur la programmation C comme le [http://www-clips.imag.fr/commun/bernard.cassagne/Introduction_ANSI_C.html polycopié de Bernard Cassagne « introduction au langage C »].

Les premiers systèmes d'exploitation étaient écrits directement en langage machine, ou bien en langage d'assembleur ; et les systèmes actuels comportent encore quelques parties de très bas niveau en langage d'assemblage...

====Notion d'appel système, norme POSIX====

La programmation de haut niveau en C est assez différente de la programmation système. De nombreuses fonctions C utilisent en fait des « appels système », c'est à dire des appels de fonctionnalités propres du système d'exploitation. Les appels système typiques sont :
* les fonctions relatives aux fichiers (création, suppression, modification...)
* les fonctions relatives à la gestion de la mémoire
* les fonctions relatives aux processus (<tt>fork</tt>)
* ...

De nombreux système d'exploitation proposent une interface [http://en.wikipedia.org/wiki/Posix POSIX] (« '''P'''ortable '''O'''perating '''S'''ystem '''I'''nterface for Uni'''x''' »). Cette norme définit entre autres un ensemble de fonctions pour utiliser les appels systèmes.
Le nombre de ces fonctions est relativement faible : une centaine ; et chacune correspond en gros à un appel système. Certaines de ces fonctions ne sont pas définies directement dans le système d'exploitation, mais dans des librairies. Pour Linux, il s'agit en général de la librairie Glibc (GNU C Library).

Par exemple, la fonction <tt>open</tt> (qui permet d'ouvrir un fichier) correspond exactement à un appel système ; alors que la fonction <tt>malloc</tt> (qui permet d'allouer dynamiquement de la mémoire dans le tas) peut générer plusieurs appels système (<tt>brk</tt> et <tt>sbrk</tt>).

Pour visualiser les appels systèmes effectués par un programme sous Linux, vous pouvez utilisez l'utilitaire <tt>strace</tt> ou <tt>ltrace</tt>. Par exemple, dans le shell :
$ strace -e trace=file ls -l 2> trace
permet de récupérer tous les appels systèmes relatifs aux fichiers lors de l'appel à <tt>ls -l</tt>. La liste des appels système est redirigée dans le fichier <tt>trace</tt> qui contiendra par exemple des lignes telles que
lstat64("Desktop", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lgetxattr("Desktop", "security.selinux", 0x8cc08e0, 255) = -1 ENODATA (No data available)
dénotant ainsi un appel aux appels système <tt>lstat64</tt> et <tt>lgetxattr</tt>...

Les principaux systèmes compatibles POSIX sont :
* Linux
* BSD (et variantes)
* Mac OS X
* Solaris

De nombreux appels systèmes sont disponibles directement (sans avoir besoin d'écrire un programme C) à travers le shell. Exécuté dans un terminal, le shell permet, en première approximation, de passer directement des commandes au système d'exploitation. (La norme POSIX définit également un ensemble de fonctions du shell. Il est donc relativement aisé de changer de système d'exploitation tant qu'on reste dans les systèmes compatibles POSIX.)

Windows d'un autre côté utilise l'interface Win32 API, qui définit plusieurs milliers de fonctions. La plupart de ces fonctions peuvent utiliser plusieurs appels système...

Les systèmes d'exploitation qui utilisent l'API Win32 sont :
* Windows, depuis Windows95.

Il est possible d'installer un environnement compatible POSIX sur une machine Windows grâce à Cygwin. (C'est d'ailleurs fortement conseillé si vous ne voulez pas installer une version de Linux ou BSD sur votre ordinateur personnel...)

====Mode noyau / mode utilisateur====

La partie fondamentale du système d'exploitation est le ''noyau'' (''kernel'' en anglais). C'est la couche de plus bas niveau.

Les fonctionnalités de très bas niveau offertes par le noyau peuvent facilement planter l'ordinateur. Il faut donc une politique de restriction pour que tous les programmes ne puissent y accéder dans leur totalité. On parle de
* mode noyau
* mode utilisateur

Dans le mode utilisateur, on ne peut accéder à ces fonctionnalités qu'a travers les appels systèmes ; dans le mode noyau, on peut tout faire... Bien entendu, un appel système doit passer momentanément en mode noyau pour pouvoir exécuter les commandes pertinentes, puis il repasse automatiquement en mode utilisateur.

La définition d'un appel système pourrait donc être « fonctionnalité atomique nécessitant un passage en mode noyau ».

====Noyau, noyau monolithique, micro-noyau====

La partie principale du système d'exploitation. C'est lui qui gère les ressources, les entrées / sorties, la communication entre processus, ... Les deux architectures principales pour un noyau sont :
* noyau monolithique
* micro-noyau
La plupart des systèmes actuels sont basés sur un noyau monolithique (Linux, BSD, Mac OS X, Solaris, Windows).

Les noyaux monolithiques sont parfois décrits comme « sans vraie structure » : une grosse soupe où cohabitent toutes les fonctionnalités du système d'exploitation. L'idée d'avoir un système unique qui gère tout est effectivement peu attirante et peut poser quelques problèmes de génie logiciel...
Un noyau monolithique est donc la couche entre le matériel et les programmes utilisateurs. Pour éviter de compiler des noyaux énormes, les noyaux monolithiques actuels utilisent en plus la notion de ''module''. Ce sont des morceaux du noyau qu'on peut charger ou décharger au besoin. Si l'interface est connue, ces modules peuvent éventuellement être en binaire, ce qui permet d'utiliser des modules propriétaires avec un noyau libre.
Sous Linux, la commande
$ lsmod
permet d'obtenir la liste des modules chargés dans le noyau.

Les micro-noyaux d'un autre coté sont basés sur la remarque que seule une toute petite partie du noyau accède effectivement au matériel. Seule cette petite partie nécessite donc des privilèges et effectue des appels système. Le reste du système d'exploitation peut être programmé en mode utilisateur, « au dessus » de cette partie. Par exemple, le micro noyau offrira la possibilité de charger un nouveau processus, mais l'ordonnanceur (qui choisit quel processus devra être chargé) ne fera pas partie du micro-noyau. On parle parfois de ''services'' / ''serveurs'' au dessus du micro-noyau.
Ceci permet d'avoir un noyau bas niveau beaucoup plus petit. Bien que ceci soit une bonne idée, et que les micro-noyaux puissent fournir de meilleurs garanties de sécurité, peu de noyaux sont effectivement des micro-noyaux. Un des problèmes est qu'un tel micro-noyau est un peu plus lent que ses cousins monolithiques. La raison principale est que dans le cas d'un micro-noyau, un appel système nécessite en fait des communications inter-processus.
Andrew Tanenbaum est un fervent défenseur des micro-noyaux.

Une autre architecture possible est d'utiliser des couches successives, chacune avec des privilèges réduits. Le système Multics avait cette architecture.
Par exemple, dans le système THE (1965), les couches étaient les suivantes :
# noyau bas niveau, multiprogrammation
# allocation de la mémoire pour les processus
# IPC (communication inter processus)
# entrées / sorties (buffer, etc.)
# programmes utilisateurs (compilation, exécution, ...)
# utilisateur (Dijkstra a annoté la description de cette couche par ''« not implemented by us »'')

Une dernière catégorie de noyau est la catégorie des machines virtuelles. Ces noyaux sont un peu à part, car il s'agit d'émuler un système d'exploitation ou du matériel particulier à l'intérieur d'un autre système d'exploitation ou matériel. Le mode noyau de la machine virtuelle est en fait dans le mode utilisateur du noyau original...

==Les processus==

===Introduction===

Allez hop commençons par une petite définition du type wikipédia :

Un processus (en anglais, process), en informatique, est défini par :
* un ensemble d'instructions à exécuter (un programme) ;
* un espace mémoire pour les données de travail ;
* éventuellement, d'autres ressources, comme des descripteurs de fichiers, des ports réseau, etc.

Un ordinateur équipé d'un système d'exploitation à temps partagé est capable d'exécuter plusieurs processus de façon « quasi- simultanée ». Par analogie avec les télécommunications, on nomme multiplexage (A. Tanenbaum parle de ''multiprogrammation'') ce procédé. S'il y a plusieurs processeurs, le système essaie de répartir les processus de manière équitable sur les processeurs disponibles.

Le processus doit être imaginé comme quelque chose qui prend du temps, donc qui a un début et (parfois) une fin. De nombreux processus ne se terminent normalement jamais : système d'exploitation, serveurs web, serveurs mail, ... D'autres processus plus légers qui ne se terminent pas sont les ''daemon'' (acronyme ''a posteriori'' de "disk and execution monitor") du monde Unix.

Certains processus sont démarrés très tôt lors de la séquence de boot. Le système d'exploitation est un tel processus. Sinon, les processus sont normalement démarrés grâce à un appel système à partir d'un autre processus. L'utilisateur peut par exemple demander explicitement un nouveau processus (sous POSIX, grâce à un <tt>fork</tt> puis <tt>exec</tt>) ; mais la plupart du temps, il le fera à travers une application, par exemple en double-cliquant sur l'icône d'un programme dans l'explorateur de fichiers.

Le système d'exploitation est chargé d'allouer les ressources (mémoires, temps processeur, entrées/sorties) nécessaires aux processus et d'assurer que le fonctionnement d'un processus n'interfère pas avec celui des autres (isolation).

Pas sûr d'avoir tout compris ? Ce n'est pas grave, essayons autrement.
:'''Définition :''' un processus est un programme en train de s'exécuter.
Cette définition implique en particulier que un programme (navigateur Firefox par exemple) peut correspondre à
* zéro processus si on ne l'a pas lancé,
* un processus si on l'a lancé,
* plusieurs processus si on l'a lancé plusieurs fois.
(''Remarque :'' pour un programme comme Firefox, il y a fort à parier que l'exécution d'une seule instance de Firefox génère de multiples sous-processus...)

Que se passe-t-il quand je démarre une application?

:L'ordinateur à une nouvelle tâche à accomplir, les instructions correspondantes sont donc envoyées au processeur. Comme il a plusieurs choses à faire le choix des instructions à exécuter n'est pas forcement simple. Il faut faire en sorte de partager le processeur entre les différentes tâches de manière équitable : c'est la fameuse gestion des processus.
:Ceci permet de réaliser plusieurs activités en ~même temps~. Grâce à la gestion des processus on peut regarder un film (obtenu par des moyens tout à fait légaux cela va de soit), tout en jouant à la dame de pique.
:(et dire que certain(e)s affirment que l'homme est mono tâche)

Plusieurs processus indépendants peuvent être ''actifs'' en même temps, mais sauf si l'ordinateur possède suffisamment de processeurs, on ne peut pas les exécuter simultanément. L'impression que plusieurs programmes s'exécutent ''en même temps'' vient simplement du fait que le processeur alterne rapidement entre eux.
Comme le temps d'exécution d'une instruction par le processeur est très court, de l'ordre de la nano-seconde, le processeur peut réaliser plusieurs centaines de millions d'instructions par seconde. Ainsi, une tranche de temps de quelques fractions de seconde, partagée entre plusieurs processus, donne à l'échelle macroscopique l'illusion de la simultanéité.

'''En résumé :''' un système d'exploitation doit la plupart du temps traiter plusieurs tâches en même temps, et comme il n'a, en général, qu'un seul processeur, il devra contourner ce problème grâce à un pseudo-parallélisme. Il traite une tâche à la fois, s'interrompt et passe à la suivante. La commutation de tâches étant très rapide, il donne l'illusion d'effectuer un traitement simultané.

===La table des processus===

L'information sur les processus est conservé par le système dans une structure de données appelée ''table des processus''. Cette table contient toutes les informations nécessaires à la gestion des processus :
* état du processus
* PID
* droits
* répertoire de travail
* pointeur vers la pile
* priorités
* ...

Sous Linux, on peut accéder à ces informations à travers le système de fichiers virtuel "Procfs". Il suffit d'aller dans le répertoire <tt>/proc/</tt>.

===Création d'un processus===

Pour les système POSIX, la création d'un processus est très simple : on utilise la fonction <tt>fork()</tt>. En C, le prototype de la fonction se trouve dans le fichier d'entêtes <tt>unistd.h</tt>.

Cette fonction prend 0 argument et permet de faire la chose suivante : elle crée un nouveau processus qui est une copie conforme du processus appelant. La seule différence visible entre l'ancien et le nouveau processus est que les processus ont un numéro (PID) différent. Pour le processus appelant, il peut obtenir le PID du nouveau processus en regardant la valeur de retour de <tt>fork</tt>. Pour le nouveau processus, cette valeur vaudra 0, et il devra utiliser la fonction <tt>getpid()</tt> pour obtenir son numéro.

Le processus appelant est appelé le ''père'' alors que le nouveau processus est appelé le ''fils''.

Notez que l'espace mémoire du processus est dupliqué plutôt que partagé. Ceci veut dire que les processus ne peuvent pas communiquer en utilisant leur variables... Par contre, les descripteurs de fichiers du fils sont hérités directement de ceux du père ; ils peuvent donc essayer de communiquer en passant par ces fichiers. (Mais cela pose de nombreux problèmes de synchronisation.)

Voici par exemple un petit programme C qui lance un processus fils:
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {

int pid ;
int pid_fils ;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
} else {
printf(" >> Je suis le fils.\n");
}

return(0);

}
Après compilation, voici un exemple d'exécution du programme résultant :
$ ./pere_fils
> Le processus 8248 démarre...
>> Je suis le fils.
>> Je suis le père (pid du fils = 8249).

Voici un autre exemple d'exécution :
$ ./pere_fils
> Le processus 8269 démarre...
>> Je suis le père (pid du fils = 8270).
>> Je suis le fils.

Notez que les numéros sont différents, et que l'ordre d'affichage n'est pas le même. Cela vient de l'ordonnancement des deux processus qui peut différer.

La technique consistant à faire
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
...
}
montre que malgré le fait que les processus soient identiques à l'origine, on peut faire beaucoup de chose.

:'''Remarque :''' <tt>fork()</tt> n'est pas directement un appel système, mais une fonction qui utilise l'appel système <tt>clone()</tt>. Cet appel système ne fait pas partie de la norme POSIX...

La deuxième technique utilisée dans les systèmes POSIX consiste à utiliser <tt>fork()</tt> pour dupliquer le processus, puis à complètement remplacer le fils par un nouveau processus. La fonction correspondante est la fonction <tt>execv</tt> :
pid = fork();
if (pid) { /* le père */
...
} else { /* le fils */
execv("/usr/bin/...", argv);
...
}
La fonction <tt>execv</tt> prend 2 arguments : une chaîne contenant le chemin d'accès à un programme, et un tableau d'arguments à donner au programme. (C'est un peu plus compliqué que ça : le premier élément du tableau est le nom du programme, et le tableau doit se terminer par un pointeur NULL.)

Une dernière fonction importante est la fonction <tt>wait(pid)</tt> qui permet à un processus d'attendre l'arrêt du processus <tt>pid</tt>.

-- ...

L'API WIN32 possède de nombreuses fonctions avec des fonctionnalités similaires. Par exemple, la fonction [http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx <tt>CreateProcess</tt>] permet de créer un nouveau processus (comme un <tt>fork</tt> suivi d'un <tt>exec</tt>), mais elle nécessite ... 10 arguments !

----

Un autre moyen de créer des processus est d'utiliser des 'processus légers' appelés Thread. Ces processus légers partage seulement une partie de la mémoire, ce qui en pratique est plus rapide pour simuler un parallélisme. On passe alors par une autre fonction. Sous GNU/Linux, lors de l'écriture d'un programme écrit en C il faut utiliser la bibliothèque pthread.h et lors de la compilation, faire un lien vers celle ci, en utilisant le paramètre -lpthread.

====Arborescence des processus dans les systèmes POSIX====

Nous avons vu que la fonction <tt>fork()</tt> permet de créer un processus fils. Le père connaît le PID de son fils : il lui est donné par la fonction <tt>fork()</tt>. Comme le fils peut lui même créer des processus fils, on obtient rapidement une arborescence de processus.

Vous pouvez visualiser cette arborescence à partir d'un terminal avec la commande <tt>pstree</tt> (l'option <tt>-p</tt> permet de demander l'affichage des PID)
$ pstree -p
init(1)─┬─acpid(25425)
├─atd(14365)
├─console-kit-dae(3632)─┬─{console-kit-dae}(3633)
│ ├─{console-kit-dae}(3641)
...
├─cron(14315)
├─dbus-daemon(15590)
├─dbus-daemon(3511)
...
├─getty(4095)
├─getty(4096)
├─getty(4097)
├─getty(4098)
├─getty(4099)
├─gpm(3528)
...
├─kded4(15769)
├─kdeinit4(15766)───klauncher(15767)
├─kdm(15564)─┬─Xorg(15566)
│ └─kdm(15573)───sh(15608)─┬─conky(15751)
│ ├─fluxbox(15703)───firefox-bin(6063)─┬─{firefox-bin}(6064)
│ │ ├─{firefox-bin}(6065)
...
│ ├─ssh-agent(15698)
│ ├─unclutter(15742)
│ ├─wicd-client(15749)
│ └─xscreensaver(15683)
...
├─rsyslogd(6850)─┬─{rsyslogd}(6140)
│ └─{rsyslogd}(6141)
├─screen(4427)─┬─bash(4428)───pstree(9307)
│ ├─bash(4429)───man(7952)───pager(7965)
│ ├─bash(4430)───vi(30568)
│ ├─bash(18395)───vi(28512)
│ └─mutt(8763)
...

Le processus <tt>init</tt> est l'ancêtre de tout les processus, il a toujours 1 comme PID.

'''Remarque :''' sous Windows, les processus ne sont pas organisé en arborescence...

====Mort d'un processus dans un système POSIX====

Un processus peut se terminer pour plusieurs raisons :
* volontairement, grâce à la fonction <tt>exit()</tt> (POSIX) ou <tt>ExitProcess()</tt> (Windows),
* à cause d'une erreur,
* en recevant un signal d'un autre processus, grâce à la fonction <tt>kill()</tt> (POSIX) ou <tt>TerminateProcess()</tt> (Windows).

Lorsqu'un processus se termine, plusieurs choix sont possibles :
* que fait-on de ses fils ?
* que fait-on de son père ?

Linux fait la chose suivante : quand un processus s'arrête,
* tous ces fils s'arrêtent,
* son père reçoit un signal le prévenant que son fils vient de mourir.

Pour que le père puisse recevoir le signal correspondant, il faut qu'il utilise la fonction <tt>wait()</tt> ou <tt>waitpid()</tt>. Tant que le parent existe et qu'il n'a pas reçu le signal disant qu'un de ces fils est mort, le processus fils n'est pas entièrement supprimé : il devient un ''zombie''. (Il n'occupe plus vraiment de place en mémoire, mais le système garde juste suffisamment d'information pour pouvoir prévenir le père si celui ci demande l'état du fils.)

'''Remarque :''' les processus Windows ne sont pas organisés sous forme d'arborescence. Chaque processus peut surveiller l'état d'un autre processus, s'il connaît son PID. Il n'y a donc pas de notion de processus ''zombie'' sous Windows.

Voici un petit programme C qui crée un processus fils, ne fait rien pendant 20 secondes, puis demande l'état de son fils :
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
int pid ;
int pid_fils ;
int w;

pid = getpid();
printf("> Le processus %i démarre...\n", pid);

pid_fils = fork();

if(pid_fils) {
printf(" >> Je suis le père (pid du fils = %i).\n",pid_fils);
printf(" >> Je suis le père et j'attends un peu.\n");
sleep(20);
printf(" >> Je suis le père et je demande l'état de mon fils.\n");
wait(&w);
printf(" >> Mon fils est mort (signal %i).\n", w);
while(1) sleep(1);
} else {
printf(" >> Je suis le fils.\n");
while (1) sleep(1);
exit(0);
}
return(0);
}
Si on tue le processus fils pendant que le père ne fait rien, le processus fils devient un zombie. Dès que le père fait le <tt>wait</tt>, il reçoit la valeur du signal qui a terminé le processus et le zombie disparaît.

Si on ne tue pas le processus fils, le père n'exécutera jamais le <tt>printf(" >> Mon fils est mort...);</tt>.

'''Remarque :''' dans un système POSIX, lorsqu'un processus meurt, ses fils deviennent ''orphelins''. Il continuent leur exécution mais sont adopté par <tt>init</tt> (PID : 1). Dans certains cas lorsque le processus est arrêté, il envoie explicitement un signal <tt>SIGTERM</tt> pour tuer ses processus fils. C'est par exemple ce qui arrive lorsqu'on lance des application à partir d'un terminal et que l'on quitte le terminal en question...

===États d'un processus===

On peut imaginer un SE dans lequel les processus pourraient être dans trois états :
* en cours d'exécution,
*bloqué : il attend un événement extérieur pour pouvoir continuer (par exemple une ressource; lorsque la ressource est disponible, il passe à l'état "prêt")
*prêt : suspendu provisoirement pour permettre l'exécution d'un autre processus.

Dans un système avec un unique processeur, au plus un processus peut se trouver dans l'état ''en cours d'exécution''. Par contre, il peut y avoir de nombreux processus dans l'état ''bloqué'' ou dans l'état ''prêt''.

Un processus peut passer d'un état à l'autre :
# de ''en exécution'' à ''bloqué'' lorsqu'une ressource n'est pas disponible (entrées / sortie par exemple),
# de ''bloqué'' à ''prêt'' si la ressource ayant provoqué le blocage devient disponible,
# de ''en exécution'' à ''prêt'' si le système décide de suspendre l'exécution du processus,
# de ''prêt'' à ''en exécution'' si le système décide de lancer l'exécution du processus.

On peut résumer ceci par le graphe de transitions suivant :

[[Image:Diagrammedétatdunprocessus.png]]

Les transition manquantes ne sont pas possible directement mais doivent passer par des transition intermédiaires.

On peut ajouter 2 états :
* ''nouveau'' pour un processus qui vient d'être créé,
* ''terminé'' pour un processus qui vient de se terminé.

Dans les systèmes type ''ordinateur de bureau'', le passage de ''nouveau'' à ''prêt'' est automatique mais dans des systèmes temps réel, un processus peut parfois attendre dans cet état.

L'état ''terminé'' est en général passager. Par exemple, lorsqu'un processus terminé est un zombie, le processus n'est conservé que dans la table des processus. La mémoire utilisé par le processus est libérée. La question de savoir si ceci est véritablement un état du processus est donc essentiellement une question de vocabulaire.

:exercice : ajouter les états ''nouveau'' et ''terminé'' et les transitions correspondantes au graphe précédent. Identifiez des situations provoquant les transitions possibles entre états.

===Ordonnancement des processus===

Nous avons vu qu'il pouvait y avoir de nombreux processus dans la table de processus (environ 150 sur mon ordinateur en ce moment même). Parmi ces processus, un seul (sur une machine à un processeur) peut se trouver dans l'état ''en exécution''. C'est au système d'exploitation de décider qui, à un moment donnée, doit se trouver dans cet état. La partie du système faisant ceci s'appelle ''ordonnanceur'' (ou ''scheduler'' en anglais).
En utilisant le contenu de la table des processus et éventuellement d'autres information, ordonnanceur doit donc gérer les transition entre états de tous les processus, et envoyer l'information nécessaire aux composants adéquat du noyau.

Comme d'habitude, l'ordonnanceur doit faire des compromis entre :
* la vitesse,
* l'utilisation de la mémoire,
* l'optimalité de la solution proposée.

'''Remarque : ''' l'ordonnanceur est lui même un processus (ou un morceau de processus dans le cas des noyaux monolithiques).

====Ordonnancement non préemptif====

'''FIFO.'''
L'algorithme d'ordonnancement le plus facile est probablement celui de type ''FIFO'' : premier arrivé, premier servi. Autrement dit, on préempte premier processus arrivé, et on l'exécute jusqu'à la fin. La seul structure de donnée est donc simplement une ''file''.

'''Plus court temps d'exécution.'''
Dans certain cas, on peut prévoir a l'avance le temps processeur dont aura besoin un processus pour s'exécuter. On peut alors choisir le processus le plus court et l'exécuter en premier. Ceci a en général tendance à diminuer le temps d'attente moyen d'un processus ; mais si des processus courts sont crées régulièrement, on peut assister à une ''famine'' : un processus peut ne jamais s'exécuter.

:exercice : trouver une suite de processus qui provoque une famine.

Ces deux exemples sont acceptables pour un ''traitement par lots'' (batch) par exemple pour des calculs numériques. Ils ne sont par contre pas du tout adaptés pour un ordinateur personnel ou un système temps réels. (Pas de ''multiprogrammation''.)

====Ordonnancement préemptif====

Pour pouvoir donner l'illusion de simultanéité, les processus sont en général exécutés par tranches de temps spécifiées à l'avance (''time slice'' en anglais). Au bout de ce temps, le noyau reçoit une interruption et examine les processus. Il peut décider de continuer le processus courant, ou bien le remplacer par un autre processus. on parle de préemption.

Windows 3.1 ou MacOS 9 étaient des systèmes ''collaboratifs'' car les processus devaient explicitement laisser la main aux autres processus. Tous les systèmes d'exploitation modernes sont maintenant préemptifs. On parle maintenant de système préemptif lorsque la préemption peut s'effectuer même sur des processus en mode noyau.
On parle parfois de noyau préemptible lorsque que les opérations en mode noyau sont elle même préemptibles.

'''Tourniquet.'''
L'algorithme le plus simple est probablement celui du tourniquet (''round Robin'' en anglais). C'est une variante de l'algorithme FIFO vu plus haut, mais qui préempte le processus courant au bout d'un moment. Si ce processus est encore en exécution, on le remet à la fin de la file des processus.

Le temps imparti à chaque processus ne doit pas être trop court (sinon, le changement de contexte prend trop de temps par rapport à l'exécution des processus) ni trop long (sinon, on perd l'illusion de parallélisme, et un processus bloqué risque d'occuper le processeur pendant trop longtemps).

Voici ce qu'on peut trouver dans le livre "Understanding the Linux kernel" :

<cite>
The choice of quantum duration is always a compromise. The rule of thumb adopted by Linux is: choose a duration as long as possible, while keeping good system response time.
</cite>

(extrait du chapitre [http://oreilly.com/catalog/linuxkernel/chapter/ch10.html "Process Scheduling"]).

'''Tourniquet avec priorité.'''
Tous les processus ne naissent pas égaux : certains ont une importance plus élevée (les processus systèmes par exemple). Dans un cas comme le précédent, tous les processus ont le même statut...
Pour corriger ce problème, on utilise parfois un algorithme similaire, mais on choisit le premier processus de priorité la plus élevé possible. Plutôt que de parcourir la file à sa rechercher, on utilise en fait plusieurs files : une pour chaque priorité.

Il faut faire attention car les processus de priorité basse risquent de ne jamais être exécutés (famine)... Par exemple, on peut diminuer petit à petit la priorité des processus qu'on exécute...

Une autre solution pour gérer les priorité en évitant certaines famines est d'exécuter toutes les files, mais pas en proportion égale. Par exemple, on choisit un processus dans les piles de priorité 1, 2, 1, 3, 1, 2, 1, 4, 1, 2, 1, 3, 1, 2, 1, ... De cette manière, les processus de la première file sont exécutés 2 fois plus de fois que ceux de la file 2, et 4 fois plus de fois que ceux de la file 3.

:exercice : donnez un algorithme pour générer la suite précédente pour un nombre donné de files. Il faut que la file ''i'' soit utilisée 2 fois plus souvent que la pile ''i+1''.

'''Répartition garantie.'''
Chaque tache reçoit la même proportion du processeur, et chaque utilisateur reçoit la même proportion également.

'''tirage aléatoire.'''
À chaque étape, on tire un "billet" au hasard, et le processus qui a le "billet gagnant" s'exécute.

Principe de priorité : Les processus qui ont été définit comme prioritaire on plus de "billet" à leur nom et ont donc plus de chance d'être tiré.

''NB : POSIX définit une commande "nice" qui permet e donner à un processus un priorité plus faible (et par conséquent, nice -x augmente cette priorité). Il est évident que tout le monde ne doit pas pouvoir utiliser cette commande, il vaut mieux que l'administrateur se réserve ce droit''

'''Ordonnancement équitable.'''

==La mémoire==

===Introduction===

RAM = Random Acces Memory. C'est ce que l'on appelle couramment la mémoire vive, elle peut être modifié à l'infini et sert à stocker temporairement les fichiers que l'ordinateur exécute.

ROM = Read Only Memory. On l'appelle aussi mémoire fixe ou mémoire morte, dès que l'on enregistre, le contenu d'une mémoire ROM ne peut pas être modifié (ex: un CD-ROM).

'''Gestion de la mémoire : '''

Lors du boot du PC, le système est chargé en mémoire.
Tout processus créé est aussi chargé dans la mémoire.

Lorsque l'on créé uns seul processus, il est plus pratique de le charger en "bas" de la mémoire, à partir de la première case de l'espace mémoire. Puis les nouveaux processus peuvent être charger par dessus. Ainsi la machine comprend où commence l'espace mémoire.

Problèmes :
1 - l'espace d'adressage ne commence pas à 0;
2 - un processus peut demander dynamiquement de la mémoire;
3 - avec un accès direct, un processus peut faire "planter" un autre.

==> Il faut avoir une couche d'abstraction au-dessus de la mémoire physique.

===Espaces d'adressage===

Et si l'on créait des espaces d'adressage distincts pour chaque processus ?
Par exemple : chaque processus utilise des adresse de 0 à n de la mémoire, on converti alors ces adresses en adresses physiques.

Certains des premiers processeurs avaient deux registres supérieurs :

- une Base => adresse physique du début de l'espace d'adressage

- une Limite => adresse physique de fin de l'espace d'adressage

Par exemple, lors de l'exécution d'un processus l'accès à une case "a" se transforme en l'accès à la Base+a et un test pour vérifier que : a+Base < Limite.

Malgré tout, ceci ne résout pas les problèmes liés au fait que des processus sont créés et disparaissent, réclament ou libèrent de la mémoire.

===Va-et-vient (swapping)===

====Idée====

Et si pour gérer tout cela on utilisait une mémoire auxiliaire (disque), pour stocker l'état de la mémoire de processus.

La mémoire vue par les processus ne correspond pas à la mémoire physique. À un instant donné, certains processus peuvent se retrouver sur le disque (dans le SWAP).

Quand un processus apparait, on lui cherche un morceau d'espace libre dans la mémoire.

====gestion de la mémoire====

* tableau de bits
* liste chaînée

====Allocation====

* first fit
* next fit
* best fit
* worst fit

===Mémoire virtuelle===

====Idée====

====Pagination====

====Traduction des adresses====

====Table des pages====

====Table inversée====

====Remplacement des pages====

==Les entrées / sorties==

----
----

==Références==

* le livre « Systèmes d'exploitation » de Andrew Tanenbaum est disponible à la BU
* la page du [http://sos.enix.org/fr/PagePrincipale projet SOS]
* la [http://www.opengroup.org/onlinepubs/009695399/nfindex.html norme POSIX:2004]
* l'[http://msdn.microsoft.com/en-us/library/aa383749(VS.85).aspx API win32]
* [http://www.lemis.com/grog/Documentation/Lions/index.php Commentary on the Sixth Edition UNIX Operating System]

Langage et concepts catégoriques pour les mathématiques et l’informatique

2009-03-13T16:00:37Z

Hatat : Pif paf la définition

This is a wiki for a course at the MSTII "École doctorale" of Grenoble.

Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...

===News===

Courses are on wednesdays morning, 9'00 to 12'00 in room F218 at the "UFR IMAG".

* first course on the 25th of February: categories, functors, natural transformations.
* March 4. : monads, adjunctions.
* March 11. : limits and colimits.

==Basic Concepts==

===Categories===

{{Definition |
A concrete category is given by:
* a collection of sets ''with structure'',
* for any pair of such sets, a set of ''morphisms'' preserving the structure.
Morphisms should compose, and the identity should be a morphism.}}

This definition is a little informal, but here are some examples:
* '''Grp''': groups and group morphisms
* '''Top''': topological spaces and continuous functions
* '''Ring''': rings and rings morphisms
* '''Vect''': vectors spaces and linear maps
* '''CPO''': CPOs and continuous functions
* ...
* '''Set''': sets and functions ('''ie''' sets with no structures, and arbitrary functions)

Generalizing the definition, we obtain the official definition of category:

{{Definition |
A category <math>\mathcal{C}</math> is given by:
* a collection <math>\mathcal{C}_o</math> of ''objects'', (notation: <math>A,B,C,X,Y,...</math>)
* for each pair <math>A,B</math> of objects, a collection <math>\mathcal{C}[A,B]</math> of ''morphisms from <math>A</math> to <math>B</math>'', (notation <math> f : A\to B</math>)
* for any object <math>A</math>, a special morphism <math>i_A : A\to A</math>
* for all objects <math>A,B,C</math>, a composition <math>\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]</math>,
such that:
* <math>f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f</math>
* <math>f\circ(g\circ h) = (f\circ g)\circ h</math> whenever it makes sense.
}}

All concrete categories are categories, and here are some examples that are not obviously concrete:
* '''Graph''': graphs and graph morphisms
* '''Rel''': sets and relations
* '''Set×Set''': pairs of sets, pairs of functions
* '''Set<math>^{op}</math>''': opposite of '''Set'''
* '''P''', whenever ('''P''',<) is a preorder (at most one morphism between objects)
* '''M''', whenever ('''M''',e,×) is a monoid (a single object)

We sometimes write <math>gf</math> instead of <math>g \circ f</math>.

In a given category <math>\mathcal{C}</math>, there are analogues of the notions of injective and surjective functions in '''Set'''. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to ''monomorphisms'', and surjectivity gives rise to ''epimorphisms''.

{{Definition |

A morphism <math>f \colon A \to B</math> is a ''monomorphism'' iff for all object <math>C</math> and morphisms <math>g,h \colon C \to A</math>, we have <math>fg = fh</math> implies <math>g = h</math>.

The morphism <math>f</math> is an ''epimorphism'' when it is a monomorphism in <math>\mathcal{C}^{op}</math>. Explicitly, when for all object <math>C</math> and morphisms <math>g,h \colon B \to C</math>, we have <math>gf = hf</math> implies <math>g = h</math>.

isomorphism
}}

Exercice
# Prove that in '''Set''', epic is equivalent to surjective and monic is equivalent to injective.
# Prove the same thing in '''Ab''', the category of commutative groups. (One thing is not obvious.)
# Prove the same thing in '''Grp''', the category of (non necessarily commutative) groups. (One thing is not obvious at all.)
# Prove that <math>i : \mathbf{Z} \to \mathbf{Q}</math> is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)
# In '''Set''', we saw that ''f'' is a monic iff <math>\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y</math>, where 1 is any singleton set. Can you find a set ''C'' such that ''f'' is epic iff <math>\forall p,q : B \to C, p\circ f = j\circ f \implies p=q</math>?
# In '''Group''', can you find an object playing a role similar to 1, ''ie'' a group ''G'' s.t. ''f'' is monic iff <math>\forall x,y : G \to A, f\circ x = f\circ y \implies x=y</math>. (We saw that we cannot use the singleton group ({e},e,×) to do that...)

===Functors===

Informally, a functor is a map between two categories which somehow preserves the structure of categories (namely, composition).

{{Definition |
A functor <math>F</math> from a category <math>\mathcal{C}</math> to a category <math>\mathcal{D}</math>, noted <math>F \colon \mathcal{C} \to \mathcal{D}</math>, is given by:
* a map which sends every object <math>A</math> of <math>\mathcal{C}</math> to an object <math>FA</math> in <math>\mathcal{D}</math>, and
* a map which sends every morphism <math>f \colon A \to B</math> in <math>\mathcal{C}</math>, to a morphism <math>Ff</math> in <math>\mathcal{D}[FA, FB]</math>,
such that:
* <math>F</math> preserves identities, i.e., <math>F(id_A) = id_{FA}</math>, and
* <math>F</math> preserves composition: <math>F(f \circ g) = F(f) \circ F(g)</math>.
}}

Exercice
# Take a functor <math>F \colon \mathcal{C} \to \mathcal{D}</math>, <math>f, g, h</math> three morphisms in <math>\mathcal{C}</math>, and <math>f' = Ff</math>, <math>g' = Fg</math>, <math>h' = Fh</math>. When <math>h' = f' \circ g'</math>, can we say something interesting about <math>f</math>, <math>g</math> and <math>h</math>?
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?
# Let ''F'' be a functor and ''F(f) = g'', if ''g'' is a mono (resp. epi), is ''f'' a mono (resp. epi)?
If not, try to find some simple and natural condition on the functor to make that true.

Answer
# No, since <math>f</math> and <math>g</math> may not even compose! This is the case when <math>f</math> has type <math>A \to B</math>, and <math>g \colon C \to D</math>, with <math>F</math> collapsing <math>D</math> and <math>A</math> (i.e., <math>FA = FD</math>).
# Functors in general do not preserve mono- nor epimorphisms. We build a counter-example for monomorphisms. Let <math>\mathbf{2}</math> be the category with two objects <math>\star</math> and <math>\bullet</math>, and exactly one morphism <math>m \colon \star \to \bullet</math>. This is a preorder, so <math>m</math> is monic. Now take <math>\mathcal{C}</math> with two objects <math>\star</math> and <math>\bullet</math>, exactly one morphism <math>m \colon \star \to \bullet</math>, and one extra morphism <math>n \colon \star \to \star</math>, different from the identity. Because of <math>n \neq id_\star</math>, yet <math>m \circ n = m \circ id</math>, <math>m</math> is not monic in <math>\mathcal{C}</math>. The functor which sends <math>\star</math> to <math>\star</math>, <math>\bullet</math> to <math>\bullet</math> and <math>m</math> in <math>\mathbf{2}</math> to <math>m</math> in <math>\mathcal{C}</math>, does not preserve monomorphisms.
# In general, the answer is (again) no. For monos, take for example the functor <math>\mathcal{C} \to \mathbf{2}</math> which sends <math>n</math> to the identity. Yet, when <math>F</math> is ''faithful'', then <math>f</math> is monic (or epic).

{{Definition |
A functor <math>F</math> is faithful when, for any two morphisms <math>f, g</math>, <math>Ff = Fg</math> implies <math>f=g</math> (<math>F</math> is injective on morphisms).
}}
{{Definition |
A functor <math>F</math> is full when, for any two objects <math>A, B</math>, if <math>g</math> is a morphism <math>FA \to FB</math>, then there exists <math>f \colon A \to B</math> with <math>Ff = g</math> (<math>F</math> is surjective on morphisms).
}}

Exercice

Find an "interesting" functor from '''Set''' to '''Group'''.

Answer
Let <math>F</math> be the functor which sends:
* every set <math>X</math> to the free group generated by <math>X</math>, and
* every function <math>f \colon X \to Y</math> to a group morphism defined by: <math>Ff(x_1^{\alpha_1}\times\dots\times x_k^{\alpha_k})=f(x_1)^{\alpha_1} \times \dots \times f(x_k)^{\alpha_k}</math>.

Exercice

If <math>\mathcal{C}</math> is a locally small category and ''A'' one of its objects, let <math>Y_A : X \mapsto \mathcal{C}[X,A]</math>. Show that this operation from objects of <math>\mathcal{C}</math> to sets can be extended into a contravariant functor <math>\mathcal{C}</math> to '''Set'''.

Answer
Let <math>f\colon X \to Y</math> be a morphism in <math>\mathcal{C}</math>, then <math>Y_A(f)</math> is expected to be a function from the set <math>\mathcal{C}[Y, A]</math> to the set <math>\mathcal{C}[X, A]</math>. We can take, for any morphism <math>m \in \mathcal{C}[Y,A]</math>: <math>Y_A(f)(m) = m \circ f</math>.

This extends <math>Y_A</math> to a contravariant functor, since <math>Y_A(id_X) = id_{\mathcal{C}[X, A]}</math> and <math>Y_A(f \circ g)(m) = m \circ (f \circ g) = (m \circ f) \circ g = (Y_A(g) \circ Y_A(f))(m)</math>.

===Natural Transformations===

{{Definition |
Let <math>F</math> and <math>G</math> be two functors <math>\mathcal{C} \to \mathcal{D}</math>. A natural transformation <math>\alpha</math> from <math>F</math> to <math>G</math> is given by:
* a morphism <math>\alpha_A \colon FA \to GA</math> in <math>\mathcal{D}</math> for every object <math>A</math> in <math>\mathcal{C}</math>,
* such that, for any morphism <math>f \colon A \to B</math>, we have <math>Gf \circ \alpha_A = \alpha_B \circ Ff</math>.
}}

Exercice

If <math>P(X)</math> is the set of permutation of a (finite) set ''X''; and <math>L(X)</math> the set of its linear orderings, we have <math>\#(L(X)) = \#(L(X)) = n!</math> where <math>n = \#(X)</math>. Thus, there is a bijection (iso in '''Set''') between ''P(X)'' and ''L(X)''.
# Show that we can extend ''P'' and ''L'' to functors from '''B''' to '''Set''', where '''B''' is the category of finite sets and bijections,
# Show that there can be no natural transformation from ''P'' to ''L'',
# Conclude that there is no natural isomorphism between ''P'' and ''L''.

==Adjunctions==

===About Limits and Colimits===

One of the main thrusts of category theory is to define concepts by
their properties rather than by explicit construction. In general this
is just called abstraction, but in good cases, concepts are
''defined'' by their properties, at least canonically if not uniquely.

The chief example of this is binary products in '''Set'''. The
product <math>A \times B</math> of two sets <math>A</math> and
<math>B</math> is generally thought of as the set of pairs <math> (x,
y) </math> with <math>x \in A</math> and <math>y \in B</math>. But
strictly speaking, or rather set-theoretically speaking, one has to
construct it by cautious use of the axioms of Zermelo-Fraenkel set
theory.

Instead, in any category <math>\mathcal{C}</math>, for any objects
<math>A</math> and <math>B</math> categorists put:

{{Definition | A
''product'' of <math>A</math> and <math>B</math> is an object <math>C</math>
with arrows
<center><math>A \xleftarrow{\pi_1} C \xrightarrow{\pi_2} B</math></center>
such that for any object <math>D</math> and arrows
<center><math>A \xleftarrow{f} D \xrightarrow{g} B</math></center>
there exists a unique arrow <math>h</math> making the diagram
[[Image:prod.png|center|Universal property of product]]
commute, i.e., <math>\pi_1 \circ h = f</math> and <math>\pi_2 \circ h = g</math>.
}}

The standard constructions in '''Set''' all have this property, and
all the non-standard ones you can think of also do, e.g., the set of
pairs <math> (\emptyset, x, y) </math> with <math>x \in A</math> and <math>y
\in B</math>.

Conversely, any set with this property is as good as any other
construction of <math>A \times B</math>.

Products are determined ''canonically'' by this property
property. We will give a more precise meaning to this in later
lectures; for now we just state:

'''Lemma.'''

For any other product <center><math>A \xleftarrow{p} E \xrightarrow{q} B</math></center> of
<math>A</math> and <math>B</math>, there is a unique isomorphism pair <math> (r, s) </math>
such that the diagrams

[[Image:prod-iso.png|upright=2]] and
[[Image:prod-iso-2.png|upright=2]]

commute.

===First examples and definition===

====So-called ''free'' constructions in algebra: monoid, group, etc====
====Their universal property, the underlying functor====
====The isomorphism between hom-sets====
====Its naturality====
====Definition====
====On to the definition with <math>\eta</math> and <math>\epsilon</math>====

===The simplicity behind definitions:2-categories and adjunctions therein===

====Definition of 2-categories====
====String diagrams====
===='''CAT''' as a 2-category====
====Adjunctions in a 2-category====

===Other basic examples===

====Discussion: any syntax defines the free something==== The issue of
variable binding.
====Adjunction between partial orders = Galois connection====
====<math>\times</math> and <math>\Rightarrow</math> in logic====
====Sets/graphs and categories====

===Monads and resolutions===

====Definition of a monad====
====String diagrams====
====Every adjunction yields a monad====
====Example of monoids again: resolutions====

===Monadic adjunctions===

====The category of resolutions====
====Eilenberg-Moore is terminal====
====Kleisli is initial====
====Monadic adjunctions====
====Algebraic theories====

===Properties===

====Composing adjunctions====
====Preservation of limits/colimits====
====Freyd's existence theorem====
====Beck's monadicity theorem====

==Limites and Colimits==

===Limits===

'''Example.''' Cartesian product.

{{ Definition | Binary product.}}

'''Theorem.''' ''The product of X and Y, if it exists, is unique up to isomorphism.'' (with proof)

'''Examples.''' Set, Grp, Ab, Part.

'''Examples.''' Preorder, Subset(E), Prop with entailment.

{{ Definition | Diagram. Cone. Limit.}}

'''Example.''' Limits in Set.

'''Examples.''' Shape of diagrams for products, pullbacks, equalizers.

'''Example.''' Monos as pullbacks.

'''Theorem.''' ''The limit of a diagram d, if it exists, is unique up to isomorphism.''

'''Theorem.''' ''A category with "all" products and equalizers has "all" limits.''

'''Theorem.''' ''A category with a terminal object and all binary products and all equalizers has all finite limits.''

===Colimits===

{{ Definition | Cocone. Colimit.}}

'''Examples.''' Sums in Set, Grp, Ab.

'''Examples.''' Shape of diagrams for sums, initial objects, pushouts, coequalizers.

'''Example.''' Epis as pushouts.

'''Theorem.''' ''The colimit of a diagram d, if it exists, is unique up to isomorphism.''

'''Example.''' The most general unifier (of two terms) is a coequalizer in the "category of substitutions".

'''Theorem.''' ''A category with "all" sums and coequalizers has "all" colimits.''

'''Theorem.''' ''A category with an initial object and all binary sums and all coequalizers has all finite colimits.''

===Limits, colimits and adjunctions===

'''Theorem.''' ''A right adjoint preserves limits. A left adjoint preserves colimits.'' (with proof of existence)

'''Example.''' The adjunction between Set and Grp

===Sums and products===

A category is ''distributive'' if the canonical map from AxB+AxC to Ax(B+C) is an isomorphism.

A category is ''extensive'' if the canonical functor + from C/A x C/B to C/(A+B) is an equivalence.

'''Example.''' "if..then..else.." from B=1+1 and extensivity.

==Course Complements, references==

One of the best books about category theory is
* Saunder MacLane, ''"Categories for the Working Mathematician"''.
It is a little "dry", in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.

I haven't really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].

Langage et concepts catégoriques pour les mathématiques et l’informatique

2009-03-10T14:59:06Z

Hatat : /* Natural Transformations */

This is a wiki for a course at the MSTII "École doctorale" of Grenoble.

Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...

===News===

Courses are on wednesdays morning, 9'00 to 12'00 in room F218 at the "UFR IMAG".

* first course on the 25th of February: categories, functors, natural transformations.

==Basic Concepts==

===Categories===

{{Definition |
A concrete category is given by:
* a collection of sets ''with structure'',
* for any pair of such sets, a set of ''morphisms'' preserving the structure.
Morphisms should compose, and the identity should be a morphism.}}

This definition is a little informal, but here are some examples:
* '''Grp''': groups and group morphisms
* '''Top''': topological spaces and continuous functions
* '''Ring''': rings and rings morphisms
* '''Vect''': vectors spaces and linear maps
* '''CPO''': CPOs and continuous functions
* ...
* '''Set''': sets and functions ('''ie''' sets with no structures, and arbitrary functions)

Generalizing the definition, we obtain the official definition of category:

{{Definition |
A category <math>\mathcal{C}</math> is given by:
* a collection <math>\mathcal{C}_o</math> of ''objects'', (notation: <math>A,B,C,X,Y,...</math>)
* for each pair <math>A,B</math> of objects, a collection <math>\mathcal{C}[A,B]</math> of ''morphisms from <math>A</math> to <math>B</math>'', (notation <math> f : A\to B</math>)
* for any object <math>A</math>, a special morphism <math>i_A : A\to A</math>
* for all objects <math>A,B,C</math>, a composition <math>\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]</math>,
such that:
* <math>f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f</math>
* <math>f\circ(g\circ h) = (f\circ g)\circ h</math> whenever it makes sense.
}}

All concrete categories are categories, and here are some examples that are not obviously concrete:
* '''Graph''': graphs and graph morphisms
* '''Rel''': sets and relations
* '''Set×Set''': pairs of sets, pairs of functions
* '''Set<math>^{op}</math>''': opposite of '''Set'''
* '''P''', whenever ('''P''',<) is a preorder (at most one morphism between objects)
* '''M''', whenever ('''M''',e,×) is a monoid (a single object)

We sometimes write <math>gf</math> instead of <math>g \circ f</math>.

In a given category <math>\mathcal{C}</math>, there are analogues of the notions of injective and surjective functions in '''Set'''. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to ''monomorphisms'', and surjectivity gives rise to ''epimorphisms''.

{{Definition |

A morphism <math>f \colon A \to B</math> is a ''monomorphism'' iff for all object <math>C</math> and morphisms <math>g,h \colon C \to A</math>, we have <math>fg = fh</math> implies <math>g = h</math>.

The morphism <math>f</math> is an ''epimorphism'' when it is a monomorphism in <math>\mathcal{C}^{op}</math>. Explicitly, when for all object <math>C</math> and morphisms <math>g,h \colon B \to C</math>, we have <math>gf = hf</math> implies <math>g = h</math>.

isomorphism
}}

Exercice
# Prove that in '''Set''', epic is equivalent to surjective and monic is equivalent to injective.
# Prove the same thing in '''Ab''', the category of commutative groups. (One thing is not obvious.)
# Prove the same thing in '''Grp''', the category of (non necessarily commutative) groups. (One thing is not obvious at all.)
# Prove that <math>i : \mathbf{Z} \to \mathbf{Q}</math> is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)
# In '''Set''', we saw that ''f'' is a monic iff <math>\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y</math>, where 1 is any singleton set. Can you find a set ''C'' such that ''f'' is epic iff <math>\forall p,q : B \to C, p\circ f = j\circ f \implies p=q</math>?
# In '''Group''', can you find an object playing a role similar to 1, ''ie'' a group ''G'' s.t. ''f'' is monic iff <math>\forall x,y : G \to A, f\circ x = f\circ y \implies x=y</math>. (We saw that we cannot use the singleton group ({e},e,×) to do that...)

===Functors===

Informally, a functor is a map between two categories which somehow preserves the structure of categories (namely, composition).

{{Definition |
A functor <math>F</math> from a category <math>\mathcal{C}</math> to a category <math>\mathcal{D}</math>, noted <math>F \colon \mathcal{C} \to \mathcal{D}</math>, is given by:
* a map which sends every object <math>A</math> of <math>\mathcal{C}</math> to an object <math>FA</math> in <math>\mathcal{D}</math>, and
* a map which sends every morphism <math>f \colon A \to B</math> in <math>\mathcal{C}</math>, to a morphism <math>Ff</math> in <math>\mathcal{D}[FA, FB]</math>,
such that:
* <math>F</math> preserves identities, i.e., <math>F(id_A) = id_{FA}</math>, and
* <math>F</math> preserves composition: <math>F(f \circ g) = F(f) \circ F(g)</math>.
}}

Exercice
# Take a functor <math>F \colon \mathcal{C} \to \mathcal{D}</math>, <math>f, g, h</math> three morphisms in <math>\mathcal{C}</math>, and <math>f' = Ff</math>, <math>g' = Fg</math>, <math>h' = Fh</math>. When <math>h' = f' \circ g'</math>, can we say something interesting about <math>f</math>, <math>g</math> and <math>h</math>?
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?
# Let ''F'' be a functor and ''F(f) = g'', if ''g'' is a mono (resp. epi), is ''f'' a mono (resp. epi)?
If not, try to find some simple and natural condition on the functor to make that true.

Answer
# No, since <math>f</math> and <math>g</math> may not even compose! This is the case when <math>f</math> has type <math>A \to B</math>, and <math>g \colon C \to D</math>, with <math>F</math> collapsing <math>D</math> and <math>A</math> (i.e., <math>FA = FD</math>).
# Functors in general do not preserve mono- nor epimorphisms. We build a counter-example for monomorphisms. Let <math>\mathbf{2}</math> be the category with two objects <math>\star</math> and <math>\bullet</math>, and exactly one morphism <math>m \colon \star \to \bullet</math>. This is a preorder, so <math>m</math> is monic. Now take <math>\mathcal{C}</math> with two objects <math>\star</math> and <math>\bullet</math>, exactly one morphism <math>m \colon \star \to \bullet</math>, and one extra morphism <math>n \colon \star \to \star</math>, different from the identity. Because of <math>n \neq id_\star</math>, yet <math>m \circ n = m \circ id</math>, <math>m</math> is not monic in <math>\mathcal{C}</math>. The functor which sends <math>\star</math> to <math>\star</math>, <math>\bullet</math> to <math>\bullet</math> and <math>m</math> in <math>\mathbf{2}</math> to <math>m</math> in <math>\mathcal{C}</math>, does not preserve monomorphisms.
# In general, the answer is (again) no. For monos, take for example the functor <math>\mathcal{C} \to \mathbf{2}</math> which sends <math>n</math> to the identity. Yet, when <math>F</math> is ''faithful'', then <math>f</math> is monic (or epic).

{{Definition |
A functor <math>F</math> is faithful when, for any two morphisms <math>f, g</math>, <math>Ff = Fg</math> implies <math>f=g</math> (<math>F</math> is injective on morphisms).
}}
{{Definition |
A functor <math>F</math> is full when, for any two objects <math>A, B</math>, if <math>g</math> is a morphism <math>FA \to FB</math>, then there exists <math>f \colon A \to B</math> with <math>Ff = g</math> (<math>F</math> is surjective on morphisms).
}}

Exercice

Find an "interesting" functor from '''Set''' to '''Group'''.

Answer
Let <math>F</math> be the functor which sends:
* every set <math>X</math> to the free group generated by <math>X</math>, and
* every function <math>f \colon X \to Y</math> to a group morphism defined by: <math>Ff(x_1^{\alpha_1}\times\dots\times x_k^{\alpha_k})=f(x_1)^{\alpha_1} \times \dots \times f(x_k)^{\alpha_k}</math>.

Exercice

If <math>\mathcal{C}</math> is a locally small category and ''A'' one of its objects, let <math>Y_A : X \mapsto \mathcal{C}[X,A]</math>. Show that this operation from objects of <math>\mathcal{C}</math> to sets can be extended into a contravariant functor <math>\mathcal{C}</math> to '''Set'''.

Answer
Let <math>f\colon X \to Y</math> be a morphism in <math>\mathcal{C}</math>, then <math>Y_A(f)</math> is expected to be a function from the set <math>\mathcal{C}[Y, A]</math> to the set <math>\mathcal{C}[X, A]</math>. We can take, for any morphism <math>m \in \mathcal{C}[Y,A]</math>: <math>Y_A(f)(m) = m \circ f</math>.

This extends <math>Y_A</math> to a contravariant functor, since <math>Y_A(id_X) = id_{\mathcal{C}[X, A]}</math> and <math>Y_A(f \circ g)(m) = m \circ (f \circ g) = (m \circ f) \circ g = (Y_A(g) \circ Y_A(f))(m)</math>.

===Natural Transformations===

{{Definition |
Let <math>F</math> and <math>G</math> be two functors <math>\mathcal{C} \to \mathcal{D}</math>. A natural transformation <math>\alpha</math> from <math>F</math> to <math>G</math> is given by:
* a morphism <math>\alpha_A \colon FA \to GA</math> in <math>\mathcal{D}</math> for every object <math>A</math> in <math>\mathcal{C}</math>,
* such that, for any morphism <math>f \colon A \to B</math>, we have <math>Gf \circ \alpha_A = \alpha_B \circ Ff</math>.
}}

Exercice

If <math>P(X)</math> is the set of permutation of a (finite) set ''X''; and <math>L(X)</math> the set of its linear orderings, we have <math>\#(L(X)) = \#(L(X)) = n!</math> where <math>n = \#(X)</math>. Thus, there is a bijection (iso in '''Set''') between ''P(X)'' and ''L(X)''.
# Show that we can extend ''P'' and ''L'' to functors from '''B''' to '''Set''', where '''B''' is the category of finite sets and bijections,
# Show that there can be no natural transformation from ''P'' to ''L'',
# Conclude that there is no natural isomorphism between ''P'' and ''L''.

==Limits and colimits==

One of the main thrusts of category theory is to define concepts by
their properties rather than by explicit construction. In general this
is just called abstraction, but in good cases, concepts are
''defined'' by their properties, at least canonically if not uniquely.

The chief example of this is binary products in '''Set'''. The
product <math>A \times B</math> of two sets <math>A</math> and
<math>B</math> is generally thought of as the set of pairs <math> (x,
y) </math> with <math>x \in A</math> and <math>y \in B</math>. But
strictly speaking, or rather set-theoretically speaking, one has to
construct it by cautious use of the axioms of Zermelo-Fraenkel set
theory.

Instead, in any category <math>\mathcal{C}</math>, for any objects
<math>A</math> and <math>B</math> categorists put:

{{Definition | A
''product'' of <math>A</math> and <math>B</math> is an object <math>C</math>
with arrows
<center><math>A \xleftarrow{\pi_1} C \xrightarrow{\pi_2} B</math></center>
such that for any object <math>D</math> and arrows
<center><math>A \xleftarrow{f} D \xrightarrow{g} B</math></center>
there exists a unique arrow <math>h</math> making the diagram
[[Image:prod.png|center|Universal property of product]]
commute, i.e., <math>\pi_1 \circ h = f</math> and <math>\pi_2 \circ h = g</math>.
}}

The standard constructions in '''Set''' all have this property, and
all the non-standard ones you can think of also do, e.g., the set of
pairs <math> (\emptyset, x, y) </math> with <math>x \in A</math> and <math>y
\in B</math>.

Conversely, any set with this property is as good as any other
construction of <math>A \times B</math>.

Products are determined ''canonically'' by this property
property. We will give a more precise meaning to this in later
lectures; for now we just state:

'''Lemma.'''

For any other product <center><math>A \xleftarrow{p} E \xrightarrow{q} B</math></center> of
<math>A</math> and <math>B</math>, there is a unique isomorphism pair <math> (r, s) </math>
such that the diagrams

[[Image:prod-iso.png|upright=2]] and
[[Image:prod-iso-2.png|upright=2]]

commute.

==Adjunctions==

===First examples and definition===

====So-called ''free'' constructions in algebra: monoid, group, etc====
====Their universal property, the underlying functor====
====The isomorphism between hom-sets====
====Its naturality====
====Definition====
====On to the definition with <math>\eta</math> and <math>\epsilon</math>====

===The simplicity behind definitions:2-categories and adjunctions therein===

====Definition of 2-categories====
====String diagrams====
===='''CAT''' as a 2-category====
====Adjunctions in a 2-category====

===Other basic examples===

====Discussion: any syntax defines the free something==== The issue of
variable binding.
====Adjunction between partial orders = Galois connection====
====<math>\times</math> and <math>\Rightarrow</math> in logic====
====Sets/graphs and categories====

===Monads and resolutions===

====Definition of a monad====
====String diagrams====
====Every adjunction yields a monad====
====Example of monoids again: resolutions====

===Monadic adjunctions===

====The category of resolutions====
====Eilenberg-Moore is terminal====
====Kleisli is initial====
====Monadic adjunctions====
====Algebraic theories====

===Properties===

====Composing adjunctions====
====Preservation of limits/colimits====
====Freyd's existence theorem====
====Beck's monadicity theorem====

==Course Complements, references==

One of the best books about category theory is
* Saunder MacLane, ''"Categories for the Working Mathematician"''.
It is a little "dry", in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.

I haven't really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].

Langage et concepts catégoriques pour les mathématiques et l’informatique

2009-03-10T14:51:54Z

Hatat : /* Functors */ Exos corrigés

This is a wiki for a course at the MSTII "École doctorale" of Grenoble.

Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...

===News===

Courses are on wednesdays morning, 9'00 to 12'00 in room F218 at the "UFR IMAG".

* first course on the 25th of February: categories, functors, natural transformations.

==Basic Concepts==

===Categories===

{{Definition |
A concrete category is given by:
* a collection of sets ''with structure'',
* for any pair of such sets, a set of ''morphisms'' preserving the structure.
Morphisms should compose, and the identity should be a morphism.}}

This definition is a little informal, but here are some examples:
* '''Grp''': groups and group morphisms
* '''Top''': topological spaces and continuous functions
* '''Ring''': rings and rings morphisms
* '''Vect''': vectors spaces and linear maps
* '''CPO''': CPOs and continuous functions
* ...
* '''Set''': sets and functions ('''ie''' sets with no structures, and arbitrary functions)

Generalizing the definition, we obtain the official definition of category:

{{Definition |
A category <math>\mathcal{C}</math> is given by:
* a collection <math>\mathcal{C}_o</math> of ''objects'', (notation: <math>A,B,C,X,Y,...</math>)
* for each pair <math>A,B</math> of objects, a collection <math>\mathcal{C}[A,B]</math> of ''morphisms from <math>A</math> to <math>B</math>'', (notation <math> f : A\to B</math>)
* for any object <math>A</math>, a special morphism <math>i_A : A\to A</math>
* for all objects <math>A,B,C</math>, a composition <math>\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]</math>,
such that:
* <math>f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f</math>
* <math>f\circ(g\circ h) = (f\circ g)\circ h</math> whenever it makes sense.
}}

All concrete categories are categories, and here are some examples that are not obviously concrete:
* '''Graph''': graphs and graph morphisms
* '''Rel''': sets and relations
* '''Set×Set''': pairs of sets, pairs of functions
* '''Set<math>^{op}</math>''': opposite of '''Set'''
* '''P''', whenever ('''P''',<) is a preorder (at most one morphism between objects)
* '''M''', whenever ('''M''',e,×) is a monoid (a single object)

We sometimes write <math>gf</math> instead of <math>g \circ f</math>.

In a given category <math>\mathcal{C}</math>, there are analogues of the notions of injective and surjective functions in '''Set'''. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to ''monomorphisms'', and surjectivity gives rise to ''epimorphisms''.

{{Definition |

A morphism <math>f \colon A \to B</math> is a ''monomorphism'' iff for all object <math>C</math> and morphisms <math>g,h \colon C \to A</math>, we have <math>fg = fh</math> implies <math>g = h</math>.

The morphism <math>f</math> is an ''epimorphism'' when it is a monomorphism in <math>\mathcal{C}^{op}</math>. Explicitly, when for all object <math>C</math> and morphisms <math>g,h \colon B \to C</math>, we have <math>gf = hf</math> implies <math>g = h</math>.

isomorphism
}}

Exercice
# Prove that in '''Set''', epic is equivalent to surjective and monic is equivalent to injective.
# Prove the same thing in '''Ab''', the category of commutative groups. (One thing is not obvious.)
# Prove the same thing in '''Grp''', the category of (non necessarily commutative) groups. (One thing is not obvious at all.)
# Prove that <math>i : \mathbf{Z} \to \mathbf{Q}</math> is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)
# In '''Set''', we saw that ''f'' is a monic iff <math>\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y</math>, where 1 is any singleton set. Can you find a set ''C'' such that ''f'' is epic iff <math>\forall p,q : B \to C, p\circ f = j\circ f \implies p=q</math>?
# In '''Group''', can you find an object playing a role similar to 1, ''ie'' a group ''G'' s.t. ''f'' is monic iff <math>\forall x,y : G \to A, f\circ x = f\circ y \implies x=y</math>. (We saw that we cannot use the singleton group ({e},e,×) to do that...)

===Functors===

Informally, a functor is a map between two categories which somehow preserves the structure of categories (namely, composition).

{{Definition |
A functor <math>F</math> from a category <math>\mathcal{C}</math> to a category <math>\mathcal{D}</math>, noted <math>F \colon \mathcal{C} \to \mathcal{D}</math>, is given by:
* a map which sends every object <math>A</math> of <math>\mathcal{C}</math> to an object <math>FA</math> in <math>\mathcal{D}</math>, and
* a map which sends every morphism <math>f \colon A \to B</math> in <math>\mathcal{C}</math>, to a morphism <math>Ff</math> in <math>\mathcal{D}[FA, FB]</math>,
such that:
* <math>F</math> preserves identities, i.e., <math>F(id_A) = id_{FA}</math>, and
* <math>F</math> preserves composition: <math>F(f \circ g) = F(f) \circ F(g)</math>.
}}

Exercice
# Take a functor <math>F \colon \mathcal{C} \to \mathcal{D}</math>, <math>f, g, h</math> three morphisms in <math>\mathcal{C}</math>, and <math>f' = Ff</math>, <math>g' = Fg</math>, <math>h' = Fh</math>. When <math>h' = f' \circ g'</math>, can we say something interesting about <math>f</math>, <math>g</math> and <math>h</math>?
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?
# Let ''F'' be a functor and ''F(f) = g'', if ''g'' is a mono (resp. epi), is ''f'' a mono (resp. epi)?
If not, try to find some simple and natural condition on the functor to make that true.

Answer
# No, since <math>f</math> and <math>g</math> may not even compose! This is the case when <math>f</math> has type <math>A \to B</math>, and <math>g \colon C \to D</math>, with <math>F</math> collapsing <math>D</math> and <math>A</math> (i.e., <math>FA = FD</math>).
# Functors in general do not preserve mono- nor epimorphisms. We build a counter-example for monomorphisms. Let <math>\mathbf{2}</math> be the category with two objects <math>\star</math> and <math>\bullet</math>, and exactly one morphism <math>m \colon \star \to \bullet</math>. This is a preorder, so <math>m</math> is monic. Now take <math>\mathcal{C}</math> with two objects <math>\star</math> and <math>\bullet</math>, exactly one morphism <math>m \colon \star \to \bullet</math>, and one extra morphism <math>n \colon \star \to \star</math>, different from the identity. Because of <math>n \neq id_\star</math>, yet <math>m \circ n = m \circ id</math>, <math>m</math> is not monic in <math>\mathcal{C}</math>. The functor which sends <math>\star</math> to <math>\star</math>, <math>\bullet</math> to <math>\bullet</math> and <math>m</math> in <math>\mathbf{2}</math> to <math>m</math> in <math>\mathcal{C}</math>, does not preserve monomorphisms.
# In general, the answer is (again) no. For monos, take for example the functor <math>\mathcal{C} \to \mathbf{2}</math> which sends <math>n</math> to the identity. Yet, when <math>F</math> is ''faithful'', then <math>f</math> is monic (or epic).

{{Definition |
A functor <math>F</math> is faithful when, for any two morphisms <math>f, g</math>, <math>Ff = Fg</math> implies <math>f=g</math> (<math>F</math> is injective on morphisms).
}}
{{Definition |
A functor <math>F</math> is full when, for any two objects <math>A, B</math>, if <math>g</math> is a morphism <math>FA \to FB</math>, then there exists <math>f \colon A \to B</math> with <math>Ff = g</math> (<math>F</math> is surjective on morphisms).
}}

Exercice

Find an "interesting" functor from '''Set''' to '''Group'''.

Answer
Let <math>F</math> be the functor which sends:
* every set <math>X</math> to the free group generated by <math>X</math>, and
* every function <math>f \colon X \to Y</math> to a group morphism defined by: <math>Ff(x_1^{\alpha_1}\times\dots\times x_k^{\alpha_k})=f(x_1)^{\alpha_1} \times \dots \times f(x_k)^{\alpha_k}</math>.

Exercice

If <math>\mathcal{C}</math> is a locally small category and ''A'' one of its objects, let <math>Y_A : X \mapsto \mathcal{C}[X,A]</math>. Show that this operation from objects of <math>\mathcal{C}</math> to sets can be extended into a contravariant functor <math>\mathcal{C}</math> to '''Set'''.

Answer
Let <math>f\colon X \to Y</math> be a morphism in <math>\mathcal{C}</math>, then <math>Y_A(f)</math> is expected to be a function from the set <math>\mathcal{C}[Y, A]</math> to the set <math>\mathcal{C}[X, A]</math>. We can take, for any morphism <math>m \in \mathcal{C}[Y,A]</math>: <math>Y_A(f)(m) = m \circ f</math>.

This extends <math>Y_A</math> to a contravariant functor, since <math>Y_A(id_X) = id_{\mathcal{C}[X, A]}</math> and <math>Y_A(f \circ g)(m) = m \circ (f \circ g) = (m \circ f) \circ g = (Y_A(g) \circ Y_A(f))(m)</math>.

===Natural Transformations===

...blabla...

Exercice

If <math>P(X)</math> is the set of permutation of a (finite) set ''X''; and <math>L(X)</math> the set of its linear orderings, we have <math>\#(L(X)) = \#(L(X)) = n!</math> where <math>n = \#(X)</math>. Thus, there is a bijection (iso in '''Set''') between ''P(X)'' and ''L(X)''.
# Show that we can extend ''P'' and ''L'' to functors from '''B''' to '''Set''', where '''B''' is the category of finite sets and bijections,
# Show that there can be no natural transformation from ''P'' to ''L'',
# Conclude that there is no natural isomorphism between ''P'' and ''L''.
==Limits and colimits==

One of the main thrusts of category theory is to define concepts by
their properties rather than by explicit construction. In general this
is just called abstraction, but in good cases, concepts are
''defined'' by their properties, at least canonically if not uniquely.

The chief example of this is binary products in '''Set'''. The
product <math>A \times B</math> of two sets <math>A</math> and
<math>B</math> is generally thought of as the set of pairs <math> (x,
y) </math> with <math>x \in A</math> and <math>y \in B</math>. But
strictly speaking, or rather set-theoretically speaking, one has to
construct it by cautious use of the axioms of Zermelo-Fraenkel set
theory.

Instead, in any category <math>\mathcal{C}</math>, for any objects
<math>A</math> and <math>B</math> categorists put:

{{Definition | A
''product'' of <math>A</math> and <math>B</math> is an object <math>C</math>
with arrows
<center><math>A \xleftarrow{\pi_1} C \xrightarrow{\pi_2} B</math></center>
such that for any object <math>D</math> and arrows
<center><math>A \xleftarrow{f} D \xrightarrow{g} B</math></center>
there exists a unique arrow <math>h</math> making the diagram
[[Image:prod.png|center|Universal property of product]]
commute, i.e., <math>\pi_1 \circ h = f</math> and <math>\pi_2 \circ h = g</math>.
}}

The standard constructions in '''Set''' all have this property, and
all the non-standard ones you can think of also do, e.g., the set of
pairs <math> (\emptyset, x, y) </math> with <math>x \in A</math> and <math>y
\in B</math>.

Conversely, any set with this property is as good as any other
construction of <math>A \times B</math>.

Products are determined ''canonically'' by this property
property. We will give a more precise meaning to this in later
lectures; for now we just state:

'''Lemma.'''

For any other product <center><math>A \xleftarrow{p} E \xrightarrow{q} B</math></center> of
<math>A</math> and <math>B</math>, there is a unique isomorphism pair <math> (r, s) </math>
such that the diagrams

[[Image:prod-iso.png|upright=2]] and
[[Image:prod-iso-2.png|upright=2]]

commute.

==Adjunctions==

===First examples and definition===

====So-called ''free'' constructions in algebra: monoid, group, etc====
====Their universal property, the underlying functor====
====The isomorphism between hom-sets====
====Its naturality====
====Definition====
====On to the definition with <math>\eta</math> and <math>\epsilon</math>====

===The simplicity behind definitions:2-categories and adjunctions therein===

====Definition of 2-categories====
====String diagrams====
===='''CAT''' as a 2-category====
====Adjunctions in a 2-category====

===Other basic examples===

====Discussion: any syntax defines the free something==== The issue of
variable binding.
====Adjunction between partial orders = Galois connection====
====<math>\times</math> and <math>\Rightarrow</math> in logic====
====Sets/graphs and categories====

===Monads and resolutions===

====Definition of a monad====
====String diagrams====
====Every adjunction yields a monad====
====Example of monoids again: resolutions====

===Monadic adjunctions===

====The category of resolutions====
====Eilenberg-Moore is terminal====
====Kleisli is initial====
====Monadic adjunctions====
====Algebraic theories====

===Properties===

====Composing adjunctions====
====Preservation of limits/colimits====
====Freyd's existence theorem====
====Beck's monadicity theorem====

==Course Complements, references==

One of the best books about category theory is
* Saunder MacLane, ''"Categories for the Working Mathematician"''.
It is a little "dry", in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.

I haven't really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].

Modèle:Boîte déroulante début

2009-03-10T13:37:50Z

Hatat :

Modèle:Boîte déroulante

2009-03-10T13:36:32Z

Hatat :

Modèle:Boîte déroulante

2009-03-10T13:26:32Z

Hatat :

{{#ifeq:{{{br|yes}}}|yes| |}}
<div style="margin-right:.5em;" align="{{#if:{{{alignB|}}}|{{{alignB}}}|left}}">
<div class="NavFrame" style="margin-top:{{{margeHaut|0em}}}; margin-bottom:{{{margeBas|0.5em}}}; width:{{{largeur|99%}}}; border-style:solid; -moz-border-radius:{{{arrondi|0}}};border-color:{{{couleurBordure|#AAAAAA}}}; background-color:{{{couleurFondB|#FFFFFF}}};" title="{{{label|<nowiki>[Dérouler]</nowiki>}}}">
{{#if:{{{image|}}}|<div class="NavPic" style="background-color:{{{couleurFondT|#EFEFEF}}};">{{{image}}}</div>}}
<div class="NavHead" align="{{{alignT|center}}}" style="height:{{{hauteur|1.6em}}}; background-color:{{{couleurFondT|#EFEFEF}}}; color:{{{couleurTexteT|black}}}; {{#ifeq:{{{thinning|no}}}|yes|font-weight:normal;|}}">{{{titre}}}</div>
<div class="NavContent" style="margin:{{{marge|0px}}}; background:{{{couleurFond|white}}}; display:block; font-size:{{{taille|1em}}}" align="{{{align|left}}}">
{{{contenu}}}
</div>
<div class="NavEnd"></div></div></div>

Modèle:Boîte déroulante début

2009-03-10T13:24:49Z

Hatat : a déplacé Modèle:Boîte déroulante début vers Modèle:Boîte déroulante

#REDIRECT [[Modèle:Boîte déroulante]]

Modèle:Boîte déroulante

2009-03-10T13:24:49Z

Hatat : a déplacé Modèle:Boîte déroulante début vers Modèle:Boîte déroulante

Modèle:Boîte déroulante

2009-03-10T13:24:13Z

Hatat : Modèle d'une boîte dont le contenu est caché par défaut