A noter qu'il existe d'autre front-end à ftrace, notamment https://trace-cmd.org/, que je trouve assez pratique dans mon contexte.
Cet outil génère d'abord un fichier binaire, plus rapide à écrire sur disque et donc avec moins de perturbation du processus sous tests.
Ensuite on génère un fichier texte pour nous autres humains (si tant est que les syscalls soient des trucs human-readable). On peut générer ce rapport autant de fois que l'on veux, en modifiant les filtres à notre guise.
Enfin, ftrace nous autorise à instrumenter nous-même nos programmes en écrivant dans /proc. Par exemple:
fprintf(/sys/kernel/debug/tracing/trace_marker, "I am here!");
echo "Hello" > /sys/kernel/debug/tracing/trace_marker
Ces traces apparaîtront dans le log de ftrace.
(à ma connaissance, le processus qui écrit doit forcément être root)
[^] # Re: C'est pas un peu l'inverse ?
Posté par snoopy . En réponse au journal Chiffrement : on est vraiment des petits joueurs. Évalué à 3.
Suffit juste d'installer la keymap !
https://www.farah.cl/DistribucionesDeTeclado/USEngR13/index_en.html
# trace-cmd
Posté par snoopy . En réponse au journal Débugger un problème de performance avec strace. Évalué à 0.
A noter qu'il existe d'autre front-end à ftrace, notamment https://trace-cmd.org/, que je trouve assez pratique dans mon contexte.
Cet outil génère d'abord un fichier binaire, plus rapide à écrire sur disque et donc avec moins de perturbation du processus sous tests.
Ensuite on génère un fichier texte pour nous autres humains (si tant est que les syscalls soient des trucs human-readable). On peut générer ce rapport autant de fois que l'on veux, en modifiant les filtres à notre guise.
Enfin, ftrace nous autorise à instrumenter nous-même nos programmes en écrivant dans /proc. Par exemple:
fprintf(/sys/kernel/debug/tracing/trace_marker, "I am here!");
echo "Hello" > /sys/kernel/debug/tracing/trace_marker
Ces traces apparaîtront dans le log de ftrace.
(à ma connaissance, le processus qui écrit doit forcément être root)