Discussion :

[mido393]

bonsoir a tous , est c'est possible de me dire les avantages et les inconvénients a l'utilisation des fonctions de bibliotheques par rapport aux appels systèmes , merci

[dahtah]

Salut,

Les appels systemes sont les interfaces du kernel. Pour faire un appel systeme en C, tu dois le faire en asm inline. C'est quand meme un gros inconvenient.

En gros, y'a aucun avantage a utiliser les appels systemes directement. C'est pour ca que tout le monde utilise la libc (ou equivalent) car:

• Gestion des erreurs
• Gestion de la presence ou non de certains appels systemes en fonction du hardware
• Interface beaucoup plus simple
• ...

[BufferBob]

salut,

Pour faire un appel systeme en C, tu dois le faire en asm inline.

non non, pas du tout, write(2) est un appel système par exemple, pas besoin d'assembleur inline pour y faire appel

en revanche la libc dispose en interne de mécanismes de bufferisation qui vont rendre ton code plus efficace sans te fatiguer
la différence est flagrante par exemple entre :

Code :

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

1
2
3
4
5
#include <unistd.h>
int main (void) {
        while (1) write (STDOUT_FILENO, "y\n", 2);
        return 0;
}

et :

Code :

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

1
2
3
4
5
#include <stdio.h>
int main (void) {
        while (1) fwrite ("y\n", 2, 1, stdout);
        return 0;
}

Code :

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

1
2
3
4
5
$ timeout 3s ./code-write > log-write
$ timeout 3s ./code-fwrite > log-fwrite
$ wc -l log-*
164644864 log-fwrite
  3200165 log-write

[dahtah]

non non, pas du tout, write(2) est un appel système par exemple, pas besoin d'assembleur inline pour y faire appel

C'est faux. Write(2) est un wrapper implemente par la libc qui fait l'appel systeme sys_write. C'est deja un niveau d'abstraction que fourni la libc.
Un appel systeme est la definition que le kernel expose au monde, autrement dit son ABI. Tu peux ecrire un programme en C qui utilise des appels systemes sans utiliser la libc.

L'appel system pour ecrire est sys_write et tu ne peux l'appeler que en asm: http://docs.cs.up.ac.za/programming/.../syscalls.html
Si tu regardes les sources de write() dans la libc tu verras que c'est un appel a sys_write en asm inline (e/rax = 0x4). Plus d'info sur l'implemntation ici. Write(2) implemente par la libc n'est en lui meme pas un appel systeme.

[Obsidian]

C'est faux. Write(2) est un wrapper implemente par la libc qui fait l'appel systeme sys_write.

C'est ce qu'il a dit également.

C'est deja un niveau d'abstraction que fourni la libc.

Mais ça n'a pas toujours été le cas.
Tous les appels référencés dans la section 2 du manuel existent en principe dans l'ABI du kernel, même s'ils sont bufferisés par la LibC.

[BufferBob]

C'est faux. Write(2) est un wrapper implemente par la libc qui fait l'appel systeme sys_write.

ok je vois ce que tu veux dire, c'est un abus de langage en effet

sans même parler du propos de la question posée qui est celui de l’intérêt d'utiliser les fonctions de la libc VS les "syscalls" ou "wrappers de la libc qui tapent sur les syscalls" (et qui à elle seule fait sens, sans trop d'ambiguité n'est-ce pas), je te propose qu'on contacte le mainteneur pour lui indiquer la faute et qu'on intitule enfin la section 2 des manpages comme il se doit et non "system calls"

[LittleWhite]

Bonjour,

Je ne sais pas si cela a été dit (j'ai pas l'impression), mais il faut savoir que les appels systèmes sont bien plus lent que des appels "normaux", en partie, car ils doivent converser avec le kernel.

[Bktero]

N'y a t-il pas aussi une question de portabilité ?

[dahtah]

Mais ça n'a pas toujours été le cas.
Tous les appels référencés dans la section 2 du manuel existent en principe dans l'ABI du kernel, même s'ils sont bufferisés par la LibC.

Oui, c'est ce que je dis, et c'est toujours vrai. La libc n'implemente pas les appels systemes, elle ne fait que rendre les appels systemes plus simples a gerer pour le programmeur. Fondmentalement, tu n'as pas besoin de la libc pour executer un appel systeme.
La libc implemente les appels man 2 en fonction des appels systemes exportes par le kernel, et non l'inverse.

sans même parler du propos de la question posée qui est celui de l’intérêt d'utiliser les fonctions de la libc VS les "syscalls" ou "wrappers de la libc qui tapent sur les syscalls" (et qui à elle seule fait sens, sans trop d'ambiguité n'est-ce pas)

Bah non, en fait, c'est la ou on se comprends pas. Pour moi la question etait "l’intérêt d'utiliser les fonctions de la libc VS les "syscalls"" et non "l’intérêt d'utiliser les fonctions de la libc VS "wrappers de la libc qui tapent sur les syscalls""

Bonjour,
Je ne sais pas si cela a été dit (j'ai pas l'impression), mais il faut savoir que les appels systèmes sont bien plus lent que des appels "normaux", en partie, car ils doivent converser avec le kernel.

Les appels "normaux" traversent aussi le kernel, puisqu'ils utilisent plus ou moins forcement un appel systeme en arriere plan. Le gain en vitesse est due a l'intelligence mis dans la libc (buffering, ...).

Ce qui se passe reellement quant on appelle une fonction dans le code:

1. Appelle de fwrite par exemple dans la libc
2. fwrite() appel a son tour write() de la libc
3. write() de la libc fait un appel systeme en mettant les bon parametres la ou il faut dans les registres (eax = 0x4 (sys_write), parametres dans ebx. ecx. edx), puis genere une interruption 0x80. L'interruptiuon 0x80 est l'interruption dediee au appel systeme et est l'entree du kernel. Les implementations recentes utilisent sysenter (main on s'en fout)
4. La on est dans le kernel, dans le gestionnaire d'interruption. eax vaut 0x4, donc le kernel sait qu'il faut appeller write() du kernel qui a son tour fait le necessaire
5. Une fois que le kernel a fait son travail, on retourne a l'appelant en user space (libc) puis ...

Si pour vous write(2) est un appel systeme, alors comment faire un appel systeme sans la libc?

[BufferBob]

Bah non, en fait, c'est la ou on se comprends pas. Pour moi la question etait "l’intérêt d'utiliser les fonctions de la libc VS les "syscalls"" et non "l’intérêt d'utiliser les fonctions de la libc VS "wrappers de la libc qui tapent sur les syscalls""

au risque qu'on se fasse expliquer la task_struct au prochain post, peut-être qu'il convient de se préoccuper un peu plus de ce qu'a voulu dire mido393 et moins de vouloir en remontrer sur sa propre compréhension du fonctionnement du kernel et de la libc

ce que tu dis finalement, c'est qu'on ne peut de toutes façon pas faire d'appels systèmes sans transiter par la libc à moins d'écrire de l'asm inline, soit.
tu précises également "mais on s'en fout" avec lequel je suis entièrement d'accord ça n'est pas la question posée ici

la question de mido393 est de connaitre les avantages et inconvénients d'utiliser les "fonctions de bibliothèques" par rapport aux "appels systèmes" (et c'est ici que naît la question de rhétorique qui nous occupe)

pour rappel, les sections 2 et 3 des manpages s'intitulent respectivement et en français "appels système" et "fonctions de la bibliothèque", ça ne lève pas l’ambiguïté de la question initiale, vraiment ?

à quoi je lui réponds par l'exemple, en utilisant fwrite (man 3) on bénéficie d'une bufferisation interne faite par la libc qui rend le programme plus efficace qu'en utilisant write (man 2)

[LittleWhite]

Les appels "normaux", comme tout ceux de string.h, ne passe pas par le noyau, enfin j'espère
fwrite, ou les printf, cela me semble normal, c'est une écriture sur périphérique.

[mido393]

bonjour a tous , j'ai pas encore reçu la réponse , de ma questions je cherche sur internet j'ai pas trouvé , est ce que vous pouvez me dire les avantages et la inconc , merci

[Trademark]

BufferBob t'as répondu.

Je rajoute que, pour un même traitement, les appels bibliothèques utiliseront les appels systèmes et feront des choses en plus. Tout dépend des contraintes et de l'usage que tu veux faire d'une fonctionnalité.

[the Hound]

Bonjour,

La bibliothèque standard est comme son nom l'indique, standard. Elle suit une spécification qui est indépendante de la plateforme utilisée (matériel et logiciel). Ce qui veut dire qu'un programme écrit avec la bibliothèque standard est portable et peut se recompiler sous différentes architectures et systèmes : ton code écrit en C standard sous Linux devrait également pouvoir se compiler et tourner sur Windows, sur une machine différente.

Les appels systèmes, sont en revanche spécifiques au système. Les appels systèmes Linux et Windows ont des codes différents et ne font pas tout à fait la même chose. Même entre un Linux 32-bit et un 64-bit, les appels systèmes vont différer. Coder un (gros) programme directement via des appels systèmes et faire en sorte qu'il soit portable doit être une horreur. Personne ne fait ça, sauf les gens qui implémentent des bibliothèques devant interagir directement avec le kernel, et dans des soucis de performance (exemple: libc, libpthread).

Bref, pour répondre à ta question : il y a beaucoup d'avantages à utiliser une bibliothèque, ne serait-ce que pour la portabilité, les optimisations qu'elle offre comme d'autres l'ont dit, la sécurité, la documentation, etc. et trop peu à faire des system call directement.
Et surtout, comme toujours en informatique : réinventer la roue, c'est bien, mais à part à des fins pédagogiques, ça sert à rien. Surtout les wrappers d'appels systèmes, ça sert vraiment à rien.