> Systemtap veut être intégré dans Linux (j'entends par là utrace et uprobe) car
> maintenir des patchs kernel out-of-tree ça demande beaucoup de temps de
> maintenance, de gestion des versions, etc...
Effectivement, utrace et uprobe sont des candidats à l'intégration et ils sont loin d'être acceptés. Ce qui semble probable, c'est qu'à terme il y aura de quoi tracer l'userland dans la branche principale. Si un autre système que uprobe/utrace est intégré pour cela (possiblement une amélioration de ptrace), SystemTap sera sans aucun doute modifié pour utiliser ce mécanisme.
> Aussi, il y a du code userland dans Linux, comme le repertoire tools/ qui heberge les
> outils clients pour perf events. Ca permet d'avoir un developpement très synchronisé
> avec les évolutions de Linux. Là encore Systemtap aurait probablement interêt à avoir
> un repertoire tools/stap.
Je pense pas que ça soit un des buts du projet SystemTap pour le moment mais je peux me tromper (et dans ce cas, je suis intéressé par les threads correspondants). Si tu lis le thread que j'ai donné plus haut [0], il est dit que les changements requis dans SystemTap pour s'adapter au noyau sont de l'ordre de quelques uns par an. Je suis conscient que maintenir du code noyau hors de la branche principale est normalement un gros travail mais dans le cas de l'userland SystemTap, ça ne s'applique pas vraiment (mais pour uprobe/utrace bien).
[^] # Re: À propos du tracing
Posté par Krunch (courriel, site web personnel) . En réponse à la dépêche Nouvelle version 2.6.33 du noyau Linux. Évalué à 2.
> maintenir des patchs kernel out-of-tree ça demande beaucoup de temps de
> maintenance, de gestion des versions, etc...
Effectivement, utrace et uprobe sont des candidats à l'intégration et ils sont loin d'être acceptés. Ce qui semble probable, c'est qu'à terme il y aura de quoi tracer l'userland dans la branche principale. Si un autre système que uprobe/utrace est intégré pour cela (possiblement une amélioration de ptrace), SystemTap sera sans aucun doute modifié pour utiliser ce mécanisme.
> Aussi, il y a du code userland dans Linux, comme le repertoire tools/ qui heberge les
> outils clients pour perf events. Ca permet d'avoir un developpement très synchronisé
> avec les évolutions de Linux. Là encore Systemtap aurait probablement interêt à avoir
> un repertoire tools/stap.
Je pense pas que ça soit un des buts du projet SystemTap pour le moment mais je peux me tromper (et dans ce cas, je suis intéressé par les threads correspondants). Si tu lis le thread que j'ai donné plus haut [0], il est dit que les changements requis dans SystemTap pour s'adapter au noyau sont de l'ordre de quelques uns par an. Je suis conscient que maintenir du code noyau hors de la branche principale est normalement un gros travail mais dans le cas de l'userland SystemTap, ça ne s'applique pas vraiment (mais pour uprobe/utrace bien).
[0] http://article.gmane.org/gmane.linux.kernel/942001
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.