Discussion :

[tabouret]

Bonjour,

Voici une melting-pot de questions sur linux et même si je me doute que j 'aurais peu de réponses, la moindre réponse m'aidera grandement à avancer donc d'avance merci.

Besoin de confirmation :

*Si j'ai bien compris, Linux possède des niveaux de priorités entre interruptions et comme la trappe possède la priorité la plus basse, forcément une trappe ne peut interrompre une interruption matérielle par exemple?

*Concernant la pile d'un processus, le noyau initialise directement une structure pile des que la fonction est appelée (exemple main()) puis remplit cette structure des que cette fonction en appel une autre?


Ordonnancement :

*un processus créant un autre processus ou créant un thread : le processus ou thread "fils" aura t il le même quantum de temps que son père?si oui une application pourrait crée des milliers de processus et monopoliser le CPU non?

*peux t on qualifier linux standard de temps réel (temps réel non critique) puisque l on peut modifier la politique d 'ordonnancement en SCHED_RR ou SCHED_FIFO?Si oui ca veut dire qu on peux faire cohabiter des processus temps réel avec des processus classiques sur le système?

*un processus classique possède une priorité statique à 0 tandis que les processus temps réels possèdent une priorité entre 1 et 99.
mais l'appel système nice() modifie la priorité statique? ou une priorité de base affectant la priorité dynamique?
Dans le cas ou il modifie la priorité statique, cela voudrait dire que l'on peux rendre un processus classique plus prioritaire qu'un processus temps réel?
La priorité dynamique est bien calculé suivant la priorité fixe et du champs counter du PCB?

*Comment l'ordonnanceur linux est appelé pour effectuer une commutation de contexte?L'ordonnanceur définit un quantum de temps pour le processus et paramètre l'IRQ horloge en conséquence?

Système de fichier :

*Le répertoire est un fichier spécial dont l'inode pointe vers des blocs contenant les inodes des fichiers contenus dans ce repertoire.
Dans ce cas pourquoi utiliser une structure DIR pour les manipuler plutôt qu'une structure classique FILE?DIR permet-elle de lire un FILE mais à un plus haut niveau ?

*accès aux données du répertoire :
J'aimerais affiché le contenu d'un dossier via un descripteur de fichier (et non un FILE) et j'aimerais savoir pourquoi ce code ne marche pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
 
 
int main(int argc, char* argv[])
{
 
	int fd;
	char buffer[1024];
	int temp;
 
	if((fd=open(".",O_RDONLY))==-1)
		perror("erreur ouverture fichier\n");
 
	printf("debut transaction\n");
 
	while(temp=read(fd,buffer,sizeof(buffer)))
	{
		write(1,buffer,temp);
		printf("transaction en cours\n");
	}
 
 
	return 0;
}

la l'affichage sur le terminal fait en boucle : "transaction en cours"), pourtant il devrait m'afficher les blocs de données du répertoire et donc le contenu de ce répertoire.

*concernant les tubes : l'inode d'un tube ne contient pas de bloc de données donc sa table d'index pointe vers des données en RAM?

*concernant les processus noyau kupdate et bdflush : sont ils la pour vider le buffer cache (donc structure logicielle en RAM) ou bien le cache matériel?
D'ailleurs l'appel fflush() vide le buffer cache c'est bien ca?


Espace d'adressage d'un processus :

*j'aimerais récupérer l'espace d'adressage complet d un processus (région de code, données et pile) : pourquoi cat mem dans /proc ou cat maps ne marche pas?il ne m'affiche rien d'ailleurs quelle différence entre ces deux fichiers?


Gestion des pages manquantes dans la RAM :

*si Page fault dans la RAM, est ce le processeur et donc le noyau qui réalise une entrée sortie sur le disque ou bien la RAM voyant que la page est manquante fait elle même cette entrée sortie en mode DMA?
Ou bien dit autrement lors d'une écriture le processeur s'adresse directement au DD pour écrire la page ?

Gestion de la mémoire

*Quelle différence entre une zone de swap et une partition normale? la zone de swap est plus rapide oui mais pourquoi?

*la RAM gère ses cadres de page dans une table indiquant le nombre de cases de 1 case libre, le nombre de cases de 2 cases contigus libres, etc... afin d'éviter la fragmentation.
Le disque lui gère ca avec un vecteur de bit donc pourquoi ne fait il pas comme la RAM afin d'éviter la fragmentation? pour des raisons de performance?


IPC :

*Pourquoi faire un ftok() pour récupérer un identifiant externe d'IPC?ftok() utilise un numero + le nom d'un fichier pourquoi utiliser un nom de fichier pour générer une clé alors qu'un simple numéro peut faire l'affaire via un #define CLE 314 par exemple

*Concernant les régions de mémoire partagées :
shmget() definit les droits en elcture, écriture et éxécution de la région mais shmat() les définis aussi? on définit deux fois les droits de la région c'est pas logique.

Fonctions du noyau :

*Concernant les fonctions du noyau bread() et breada() : pourquoi utiliser bread() si breada() utilise la localité spatiale et donc est plus performant?

*Comment tester la validité d'un tampon vu que getblk() renvoie un tampon mais ne le teste pas alors que bread() teste le tampon?

Divers :

*J'ai lu pas mal de bouquins concernant le noyau linux et aimerait maintenant m'attaquer a la lecture du code source du noyau : existe t-il des sources entièrement commentées ou expliquées quelque part?d'une part pour une version système V et d'une autre part pour une version linux.

*Le noyau initialise le segment BSS à 0 dans ce cas pourquoi une variable non initialisée ne contient elle pas forcement la valeur 0?

*Dans un unix système V :
le noyau possède une table des processus avec des entrées de structure proc, la structure User constituant la seconde moitié du PCB du processus se situant quant à elle dans la zone U de l 'espace d'adressage du processus.pourquoi la structure User contient un pointeur vers la structure Proc? Cela ne devrait-il pas être l'inverse ?

*Comment le noyau identifie t-il root?il a un numéro spécial d'uid dont la valeur est testée lors de chaque appel système?






Voilou désolé pour le pavé un peu long je me doute de toute façon que je n'aurais pas énormément de réponses.

Merci

[LittleWhite]

Bonjour,

Beaucoup de questions intéressantes .

*Quelle différence entre une zone de swap et une partition normale? la zone de swap est plus rapide oui mais pourquoi?

La zone de swap est une partition réservée (un espace sur le disque réservé) dans laquelle le noyau copiera la mémoire lorsqu'il y a pénurie de mémoire pour les processus « actifs ». La politique pour choisir la mémoire des processus à déplacer est souvent : les processus les moins utilisés (ceux qui dorment depuis longtemps). Les raisons que je vois pour que la partition swap soit plus rapide est :

• la mémoire est possiblement un espace contigue que l'on va copier bloc par bloc (donc lecture contigue du disque) ;
• il n'y a pas d'inode ou autre arbre pour retrouver telle ou telle donnée en jeu dans ce cas.

[tabouret]

C'est vrai qu'on a pas besoin d 'inode vu que la lecture est séquentielle mais du coup on perd du temps à chercher l'information par rapport à une recherche indexée avec fonction de hachage dans le cas ou le processus recherché est tout à la fin de la zone de swap.
Le truc c'est que sur les forums anglophones, ils disent qu'une partition normale est plus rapide dans certains cas qu'une partition swap.
Et qu'avec le kernel 2.6, une partition normale est aussi rapide qu'une partition swap.

[gangsoleil]

*un processus créant un autre processus ou créant un thread : le processus ou thread "fils" aura t il le même quantum de temps que son père?si oui une application pourrait crée des milliers de processus et monopoliser le CPU non?
Un genre de fork-bomb : oui. Sauf que les algorithmes utilisés pour l'ordonnancement sont un peu plus complexes que "j'alloue un quantum, puis je mets à la fin de la file d'attente". Il y a une notion de priorité (nice), mais aussi le fait que plus un processus passe de temps sur un processeur, moins il est prioritaire.
Après, le phénomène que tu décris s'appèle famine (un processus n'arrive presque jamais au processeur) (starving en anglais), fork-bomb, ...


*peux t on qualifier linux standard de temps réel (temps réel non critique) puisque l on peut modifier la politique d 'ordonnancement en SCHED_RR ou SCHED_FIFO?Si oui ca veut dire qu on peux faire cohabiter des processus temps réel avec des processus classiques sur le système?
C'est un temps-réel "mou", par opposition au temps-réel "dur". Le seul moyen d'avoir un vrai temps-réel, c'est une carte physique (FPGA pour l'exemple), c'est à dire que tu n'as pas d'OS. À partir du moment où tu as un OS qui doit prendre du temps pour faire des choses, tu n'es plus en temps-réel dur.
Maintenant, oui, tu peux avoir un temps-réel simulé sur Linux (et d'autres OS), qui te permet de faire tourner des programmes pseudo-temps réel, parallèlement à des programmes classiques. Attention, dans ce cas précis, tous tes programmes classiques pourront être victimes de famine.

*un processus classique possède une priorité statique à 0 tandis que les processus temps réels possèdent une priorité entre 1 et 99.
mais l'appel système nice() modifie la priorité statique? ou une priorité de base affectant la priorité dynamique?
Dans le cas ou il modifie la priorité statique, cela voudrait dire que l'on peux rendre un processus classique plus prioritaire qu'un processus temps réel?
La priorité dynamique est bien calculé suivant la priorité fixe et du champs counter du PCB?
Attention, nice modifie la politesse des processus : plus la politesse est élevée (19), plus le processus laisse passer les autres. D'ailleurs, il faut (fallait ?) obligatoirement être root pour activer une politesse négative sur Linux (entre -1 et -20). J'avoue que je n'ai pas joué avec les priorité depuis longtemps, je ne me souviens pas des nombres, mais pour moi la priorité n'est pas la politesse.


D'ailleurs l'appel fflush() vide le buffer cache c'est bien ca?
fflush vide le cache oui. En langage C, fflush est limité aux flux sortants, et surtout imprimer un '\n' fait la même chose .

*si Page fault dans la RAM, est ce le processeur et donc le noyau qui réalise une entrée sortie sur le disque ou bien la RAM voyant que la page est manquante fait elle même cette entrée sortie en mode DMA?
Ou bien dit autrement lors d'une écriture le processeur s'adresse directement au DD pour écrire la page ?
La RAM ne fait rien, elle stocke. Si tu as un page fault, cela veut dire que ton système doit aller lire un cran plus loin pour essayer de trouver une information valide : cache processeur L1 puis L2 puis L3 puis RAM puis disque (qui s'occupe lui-même de gérer un cache).



*la RAM gère ses cadres de page dans une table indiquant le nombre de cases de 1 case libre, le nombre de cases de 2 cases contigus libres, etc... afin d'éviter la fragmentation.
Le disque lui gère ca avec un vecteur de bit donc pourquoi ne fait il pas comme la RAM afin d'éviter la fragmentation? pour des raisons de performance?
La fragmentation ne vient pas de là -- ou alors je n'ai pas compris ta question.
Si tu as 1234 octests à sauver, tu as par exemple 2 moyens (en fait beaucoup plus) de le stocker : soit tu prends la première zone dont la taille est supérieure ou égale à 1234, soit tu prends la plus grande zone disponible. Les 2 ont des avantages et des inconvénients, et surtout les 2 laissent des trous sur le disque -- de la fragmentation.


*Concernant les régions de mémoire partagées :
shmget() definit les droits en lecture, écriture et éxécution de la région mais shmat() les définis aussi? on définit deux fois les droits de la région c'est pas logique.
Non, on ne les définit pas 2 fois pour les mêmes : celui qui crée la zone définit des droits dessus, et ceux qui s'attachent veulent obtenir certains droits. Mais si je m'attache à une zone que je n'ai besoin que de lire, il est logique que je ne demande que les droits de lecture lors de mon attachement, même si la zone est théoriquement accessible en écriture.


*J'ai lu pas mal de bouquins concernant le noyau linux et aimerait maintenant m'attaquer a la lecture du code source du noyau : existe t-il des sources entièrement commentées ou expliquées quelque part?d'une part pour une version système V et d'une autre part pour une version linux.
https://www.kernel.org/ ?

*Le noyau initialise le segment BSS à 0 dans ce cas pourquoi une variable non initialisée ne contient elle pas forcement la valeur 0?
Une variable non initialisée est déclarée, mais la zone réellement utilisée n'est pas modifiée : tu gagnes une instruction d'écriture sur toute la zone mémoire. Et puis à quoi ça sert d'initialiser un truc qui sera affectée avant d'être utilisé, si ce n'est à faire le travail à double ?

*Comment le noyau identifie t-il root?il a un numéro spécial d'uid dont la valeur est testée lors de chaque appel système?
root a l'uid 0.



Sinon, je pense que tu es mûr pour lire le Tannenbaum sur les systèmes d'exploitations.



Voilou désolé pour le pavé un peu long je me doute de toute façon que je n'aurais pas énormément de réponses.

Merci[/QUOTE]

[tabouret]

Merci pour toutes ces réponses !

Concernant le fork-bomb :
Oui la priorité dynamique se calcul à partir du temps CPU consommé contrairement à la priorité statique.Mais ok merci de confirmer que le fork-bomb existe par exemple si je crée un millier de processus dont la moitié consomme peu le CPU (sleep()) et l'autre plus de CPU, forcément le système risque de ramer un max mais je me demandais par exemple si les éditeurs de logiciels pensaient à cette logique? du style je crée un max de processus (mais pas trop quand même pour éviter une saturation des processus systèmes) afin que mon application obtienne un temps maximum de CPU.
De plus il me semble qu'à la mort d'un fils, le père hérite de la moitié du champs counter (nombre de ticks restants CPU) du fils; Une autre logique voudrait que je crée plein de fils et que je les fasse mourir aussitôt...

Par rapport au temps réel linux

D'accord linux est en temps réel "mou" mais sais-tu si certaines threads démons s’exécutent en SCHED_RR ou SCHED_FIFO ?
RTlinux ce n'est pas du temps réel dur?

Concernant nice()
Oui il faut toujours être root pour rendre négatif une valeur de nice() mais d'accord nice() modifie la politesse et donc la priorité dynamique et non la priorité statique merci de la précision.

Concernant la fragmentation :
Oui la fragmentation existera toujours mais :
En fait la RAM est gérée via une table dont la première entrée indique le nombre de 1 page libre consécutivement, la deuxième entrée le nombre de 2 pages consécutives libres, etc...
Ainsi le noyau sait exactement ou stocker en RAM des données suivant leur taille et rapidement.
Le disque dur, d'après ce que j'ai compris, gère ça avec un vecteur de bits aussi long qu'il y a de blocs dans ce disque.Pour retrouver une infos ça prend du temps non?


J'ai déjà téléchargé le code source sur kernel.org et j'ai déjà commencé à lire les algorithmes mais je voulais juste savoir s'il y a un site qui documente ou qui explique intégralement le code source histoire de ne pas y passer trop de temps.

Concernant le BSS, exactement je me suis demandé pourquoi réalisé un travail d'écriture on perd une instruction C (donc plusieurs instructions assembleur) pour rien mais il est bien stipulé dans plusieurs manuels que le noyau initialise le BSS à 0...

Petite question annexe soit dit en passant : le but d'un hacker système est donc de mettre son uid réel ou effectif à 0 par tous les moyens donc?

Et dernière question annexe : si j'écrit un programme C avec une instruction assembleur normalement réservé au noyau (instruction illégale donc) le registre PC du processeur contient l'adresse de la prochaine instruction (ici mon instruction illégale) et cette instruction débarque sur le registre d'instruction;
C'est donc le processeur qui "voit" l'instruction et qui voit dans son registre status qu'il est en mode utilisateur et non noyau (et que c'est donc illégal) et qui en avertit le noyau?
Ou bien c'est le noyau qui check mes instructions ?

En tout cas merci de tes réponses, concernant le Tannenbaum je l'ai acheté la semaine dernière je finis d'abord Robert Love "linux kernel programming" et "le noyau linux" des éditions O'Reilly et je m'y attaque merci