Discussion :

[Jéjé34]

Bonjour,

Pour la préparation de mon examen de Systèmes, je suis en train de préparer quelques réponses a certaines questions et je voulais avoir votre avis sur celles-ci. Est-ce que vous ne voyez pas d'abbération? Est-ce qu'il y'a des réponses que je peux compléter (je pense notamment à la première) ?

Décrivez les avantages des appels systèmes et des fonctions de bibliothèques

Appels Système
- Plus rapide, moins gourmands en mémoire donc plus efficace

Fonctions de bibliothèque
- Lecture et écriture formatée
- Portabilité d'un système Unix a un autre

Quels sont les différences entre lien symbolique et lien physique?

Un lien symbolique est un fichier qui pointe sur un autre fichier.
Un lien physique est un fichier qui occupe exactement le même espace disque que le fichier vers lequel il pointe.
Avec un lien physique, si on efface le fichier cible, il continuera d'exister. Alors que si l'ont fait la même choses avec les liens symboliques, ils pointeraient dans le vide.
Autre différence: un lien symbolique peut pointer vers un autre système de fichiers ou partition, ce qui n'est pas le cas des liens physiques.

Peut-on se déplacer (lseek ou fseek) dans tous les fichiers?

Non, on ne peut se déplacer sur un fichier que si il a été ouvert (open) au préalable.
Si on considère un tube comme un fichier, on ne peut pas se déplacer sur ce dernier.

Que permet un tube nommé que ne permet pas un tube simple?

Avec un tube simple, il faut obligatoirement que les processus connaissent le processus qui a créé le tube.
Alors que les tubes nommés disposent d'un nom dans le SGF, il suffit qu'un processus appelle un tube par son nom pour lire ou écrire sur ce dernier.

Pour finir, j'ai une question pratique, je fais souvent des tests pour voir si l'utilisateur a passé le bon nombre d'argument a mon programme ou bien pour voir si des appels noyaux se sont bien déroulés.

Par exemple,

Code :

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

1
2
3
4
 if (argc != 2) {
    perror("Mauvais nombre d'arguments");
    return;
}

ou encore

Code :

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

1
2
3
4
 if (pipe(tube) == -1) {
    fprintf(stderr, "Problème de pipe");
    exit(1);
}

Quelle est la meilleure solution: utiliser perror ou bien fprintf(stderr, ...) ?
Et enfin dans quel cas utiliser return ou bien exit() ?

[Obsidian]

Bonsoir,

Appels Système
- Plus rapide, moins gourmands en mémoire donc plus efficaces

Non, ce n'est pas forcément vrai. Les appels systèmes sont les fonctions primitives proposées par le noyau d'un système d'exploitation, et à partir desquels on peut en principe construire tout le reste. Les invoquer implique notamment de passer en mode noyau, ce qui a un coût. La libc Linux les bufferise tous, pour cette raison. Parler d'avantages des uns ou des autres n'a pas vraiment de sens car tout cela dépend du contexte, et ils ont chacun leur domaine d'application.

On pourrait considérer qu'effectuer directement un appel système permet de se passer de surcouches inutiles (c'est parfois vrai) mais, en réalité, les bibliothèques sont conçues pour faire la majorité du travail en espace utilisateur et n'appeler le noyau que lorsque cela devient réellement nécessaire. De ce point de vue, elles sont plus efficaces.

Un lien physique est un fichier qui occupe exactement le même espace disque que le fichier vers lequel il pointe.

Tu as presque compris le fonctionnement des liens mais cette phrase en particulier est incorrecte. Du moins, elle peut être interprétée de travers.
Il s'agit plus précisément d'une entrée du catalogue référençant le même fichier qu'une autre entrée. Sous DOS, on aurait appelé cela une référence croisée et cela aurait synonyme de système de fichier corrompu. Sous UNIX, c'est fait pour.

En fait, toujours sous Unix, un fichier et tous ses attributs sont définis par ce que l'on appelle un inode, lui-même repéré par un nombre entier unique (mais pouvant être recyclé si le fichier est effacé). Une entrée dans le catalogue référence un inode, visible avec « ls -i ». Lorsque tu crées un lien dur, tu crées une nouvelle entrée qui référence le même inode. L'inode en question, entre autres informations, tient à jour le nombre d'entrées qui le référencent, sans savoir explicitement lesquels. Mais ce nombre est décrémenté chaque fois que l'on efface l'une d'elles avec rm, et le fichier n'est réellement effacé que lorsque ce nombre atteint zéro (et que tous ses handles ont été refermés).

Avec un tube simple, il faut obligatoirement que les processus connaissent le processus qui a créé le tube.

Même chose. Tu as globablement saisi le principe mais dans ce cas précis, il ne suffit pas de « connaître le processus » qui a crée le tube. Il faut que ces processeurs disposent chacun d'un descripteur de fichier du tube en question et il ne peuvent l'avoir obtenu que par héritage (à la suite d'un fork).

Quelle est la meilleure solution: utiliser perror ou bien fprintf(stderr, ...) ?

perror() est la plus indiquée à condition que l'appel que l'on cherche à vérifier initialise correctement la variable globale errno. Dans les autres situations, il faut écrire le message soi-même, avec fprintf(), donc.

Et enfin dans quel cas utiliser return ou bien exit() ?

return est un mot-clé standard du C. Il sert à quitter immédiatement la fonction courante en renvoyant éventuellement une valeur. Si cette fonction est main(), c'est le programme entier qui prend fin.
exit() est une fonction définie par la bibliothèque standard et prise en charge par le système d'exploitation. Cette fonction sert à mettre fin immédiatement au programme qui l'appelle, quelque soit l'endroit où cet appel se fait.

Il n'y a pas de contre-indication notoire à utiliser l'une ou l'autre approche, mais les puristes resteront en général à return dans main. Ce, d'une part, parce que return sera toujours disponible par définition tandis que exit() dépend de l'implémentation de la bibliothèque standard et de la plateforme-cible (notamment en standalone). Ensuite, appeler exit() en plein milieu d'un programme est généralement le signe que l'on s'est mis dans une impasse. Quitter violemment empêche de faire le ménage que l'on aurait fait d'habitude tout au long du fil, même s'il existe atexit() pour faire appeler automatiquement une fonction sur appel à exit(), chargée en principe de faire ce nettoyage.

[Jéjé34]

Je te remercie Obsidian, pour cette réponse très complète!