Cours CSE

De Ensiwiki
Aller à : navigation, rechercher

Quelques infos en vrac sur le cours CSE, principalement des pointeurs sur les fichiers montrés en cours pour illustrer tel ou tel point.

Bibliographie

Deux références pour aller plus loin:

  • Le noyau Linux, Daniel Bovet, Marco Cesati, chez O'Reilly
  • Operating Systems Design and Implementation, Tanenbaum, Woodhull, chez Prentice Hall

Deux références pour revoir les bases:

  • Modern Operating System, Tanenbaum, Prentice Hall
  • Operating System Concepts, Silberschatz, Galvin, Gagne, chez Wiley

Pour ceux qui voudrait des détails sur Windows:

  • Windows Internals, Russinovich, Solomon, Ionescu, chez Microsoft

Cours du lundi 1 février 2016

OS permet le partage des ressources - du processeur lui même, avec la notion de tâche et de processus - des périphériques

  • création et changement de contextes en mode user : man makecontext, swapcontext et le SEE ALSO de la page de man. On peut donc refaire un ordonnanceur de tâches à l'intérieur d'un processus complètement grâce à ces fonctions (l'intérêt est cependant limité à des applications bien particulières, ...)
  • multitâches coopératif en mode user, géré par le système : man sched_yield. Notez qu'une version intermédiaire de la spec des pthread incluait la fonction "pthread_yield()", mais elle n'a pas été retenue par le standard.
  • introduction de la notion d'interruption
  • exemple de fonction de changement de contexte en MIPS Fichier:Cse-commute.tgz. Vous pouvez le faire tourner pour de vrai sur une machine de l'Ensimag en utilisant les outils disponibles dans le module CEP de 1A [[1]] (un grand merci à Luc Michel pour la mise en place de cet environnement !)

Il faut pour cela ajouter dans votre PATH le chemin

/opt/mips-tools-cep/bin/

le mieux étant de le faire dans le .bashrc. Les outils sont qemu-system-mips pour le simulateur, à lancer avec -s -S lors de la connexion avec gdb. Les outils de compilation croisée sont préfixés par mips-elf-

En faisant dans une fenêtre

 make debug

et dans une autre

make gdb

vous exécutez le programme en pas à pas à l'aide de gdb (commande si pour avancer d'une instruction).

Pour moi ça marche sur pcserveur, contactez moi s'il y a soucis.

Cours du lundi 8 février 2016

  • Autour des interruptions
    • présentation des deux types de signaux d'interruption, sur niveau ou sur événement, et des architectures d'interruption avec des contrôleurs spécialisés (APIC/GPIC/ITC/PIC), architectures très dépendantes du processeurs et très variées, même si les concepts sous-jacents sont similaires.
    • description du traitant d'interruption, qui peut être vu comme une fonction s'exécutant dans un contexte "neuf" (sans états, dans le noyau) à chaque appel.
    • le noyau lui même peut être vu comme un super-traitant d'interruption et d'appels systèmes.
  • Les Entrées/Sorties, port mapped ou memory mapped
    • par le processeur, scrutation (polling) aussi dite entrées/sorties programmées
    • par interruption, lorsqu'une donnée est présente sur un périphérique et que l'on désire en avertir le processeur
    • analyse de la data-sheet d'un UART élémentaire, et écriture d'un code qui fait le polling pour récupérer les données, et d'un gestionnaire d'interruption relativement abstrait. Quelques règles d'écriture :
      • utiliser des defines pour identifier les offset au sein d'un périphérique (pas comme dans l'exemple qui est juste dessous), mais attention, ils dépendent du type de l'adresse de base. Ainsi, si le registre d'état est à l'offset 8, il faut écrire

  const volatile uint32_t *uart_base_addr = 0xC0000000;
  while ((*(uart_base_addr + 2) & 1) == 0); /* uart_base_addr est un pointeur sur type 32 bits */
  data =  *(uart_base_addr + 0);

      • ne pas oublier volatile pour garantir que le compilateur n'optimisera pas les accès mémoire, car sinon il ne sait pas que l'adresse lue peut voir son contenu changer. Et de fait on ne peut pas lui reprocher, car c'est un comportement qui n'existe que pour (1) les FIFOs et les registres des périphériques dont le contenu varie au gré de l'environnement, et (2) les zones de mémoire partagée dans les systèmes multiprocesseur.
      • dans le traitant d'interruption, les données du périphérique doivent être stockée dans un tampon (buffer) partagé entre le traitant et le "reste" du système. Nous verrons les détails en TD.
      • la data-sheet de l'UART Fichier:Uart.pdf pour référence

TD des mercredis 10 et 17 février 2016

Ce TD porte sur le context switch sur MIPS. Les sources initiales dont vous avez besoin sont ici Fichier:Mips-switch.tgz. Le sujet du TP est ici Media:tdlaptop_ult.pdf. Vous disposez de deux séances pour faire les questions non étoilées, mais si vous arrivez à faire ces derniers, c'est encore mieux ! Bon courage.

TP shmem du mercredi 16 mars 2016

Voici le sujet le sujet

Le fichier source en c le code

Il compilera avec un makefile du style

  
  CFLAGS += -std=gnu99
  LDLIBS+= -lSDL
  
  shmem_pong: shmem_pong.o
  
  clean:
  	rm -f shmem_pong shmem_pong.o
  
  

TP setjmp/longjmp du 23 mars 2016

Voici le sujet Media:CSE-TPjmp.pdf et le code Media:Fibojump_etd.c

TD Socket/IO asynchrone/select du 13 avril 2016

Entrées/sorties asynchrones, attente multiple et communication par socket UNIX.

le sujet

le code du client, du serveur et de log


Un makefile simple devrait suffire.

  CFLAGS+= -Wall -Werror -std=gnu99 -g
  all: client server
  server: server.o log.o 
  client: client.o log.o
  server.o: server.c log.h
  client.o: client.c log.h

le code du client bouclant en envoyant la date

Pour le lancement, la commande suivante devrait suffire

  for i in $(seq 0 7); do ./client $i; done

Exemple de code de serveur multi-client avec select

  info libc
  Puis Sockets => Connections => Server Example

TD ld/ldopen du 15 avril 2016

Ou comment éviter de dupliquer du code sur disque!

le sujet



Annales