Comme tout OS, l’IOS doit implémenter un certain nombre de principes élémentaires :
  • Gestion de processus
  • Gestion de la mémoire
  • Gestion des périphériques
  • Interface Utilisateur
  • ...
Parlons des processus, l’IOS est un Operating System multitâches coopératif (non préemptif). Chaque processus est donc responsable de laisser le processeur au processus suivant. L’IOS ne connaît pas la notion de multithreading (1 processus = 1 thread). Afin de pouvoir rapidement switcher des paquets d’une interface à une autre, l’IOS utilise le mécanisme des interruptions. Dès qu’un paquet arrive sur une interface, une interruption est levée. Le processeur a donc la possibilité de traiter le paquet en priorité. Le fait qu’un processus soit responsable de son temps sur le processeur peut ouvrir la porte à beaucoup de problèmes si ce processus entre, par exemple, dans une boucle infinie. L’IOS a pour ce cas de figure un watchdog timer qui peut terminer un processus si celui-ci prend trop de temps sur le CPU (par défaut 2*2sec). Un processus possède 6 états:
  • Create State
    • Le processus est créé par le Kernel ou par le Parser (cli / config)
    • Allocation de ressources
  • Modify State (optionel)
    • On ajoute un terminal au processus (pas de std ::in/out/err par défaut lors d’un create)
    • On lui passe certains paramètres
  • Ready State
    • Le processus est prêt à être lancé sur le processeur
  • Running State
    • Le processus est sur le processeur
    • Il peut:
      • Cèder sa place volontairement (Suspend). Il retourne en Ready State.
      • Terminer son exécution à la fin de sa tâche (Run to completion)
      • Se mettre en attente d’un évènement (Idle State)
  • Idle State
    • Le processus attend un évènement spécifique (Wait for External Event)
  • Dead State
    • Le processus s’est terminé lui-même (Self Termination)
    • Le processus a été tué par le Kernel (Killed)
    • Le processus a terminé son travail (Run to completion)
Cycle de vie d’un processus : image Il existe 4 priorités (une file FIFO/priorité) de processus afin d’en favoriser certains par rapport à d’autres :
  • Critical
  • High
  • Medium
  • Low
Le scheduler est responsable de retirer un processus en Ready State d’une file de priorité et de l’exécuter sur le CPU (Running State). Notes : Sur toutes les sources que j’ai consultées il y a seulement 4 priorités, or, lorsque l’on utilise la commande : 
#show list | inc Sched
8 650F2910 0/- Sched Preemptive
9 650F2310 0/- Sched Critical
10 650F21F0 0/- Sched High
11 650F1C10 2/- Sched Normal
12 650F1C60 0/- Sched Low
13 650F1E10 0/- Sched Preemptive ION
14 650F2180 262/- Sched Idle
15 650F0800 0/- Sched Dead
16 6535B660 0/- Sched Normal (Old)
17 6535B6C0 0/- Sched Low (Old)
On se rend compte qu’il existe une file appelée « Sched Preemptive ». Cette liste va à l’encontre du fait que l’IOS est non préemptif ! (Mes sources sont peut-être aussi un peu anciennes !) La commande permet aussi de bien visualiser les files et notamment le nombre de processus présents respectivement dans chacune d’elles. J’ai donc 262 processus en Idle State et 2 processus de priorité « Normal » en Ready State. Un processus passant à l’état « Dead » ne voit pas automatiquement ses ressources libérées, ceci explique sans doute la nécessité de garder une trace des processus « Dead » dans une file du même nom. Dans mon prochain post, j’expliquerai le fonctionnement du scheduler IOS.