> Par contre je n'ai pas compris l'utilité du tracing : c'est juste à des fins de
> monitoring ou c'est plus poussé (ce dont je suppose, mais je ne vois pas en quoi).
Ça peut être utilisé pour du monitoring mais je vois plutôt ça comme un outil de debugging et d'aide au réglage de performances.
> De plus il y a point de traçage statique et dynamique, quel sont les
> avantages/inconvénients de chacun ?
Les points de traçage statiques sont définis par le développeur du code. Il va instrumenter explicitement ce qu'il pense pouvoir être intéressant. Les points de traçages dynamiques sont définis par l'utilisateur du code. Cela permet donc d'oberver des choses auxquelles on n'a pas pensé a priori mais ça nécessite une meilleure compréhension du système à observer.
D'un point de vu non développeur, en gros, pour utiliser les points de traçage dynamiques, tu fais des echo 1 > /proc/sys/whatever/debug alors que pour le dynamiques, il faut dire explicitement ce que tu veux observer au niveau du code.
> Sinon autre chose, à propos des "régressions" : est-ce que c'est une
> manière élégante de dire "bugs" ?
Une régression est un bug qui n'existait pas dans la version précédente (en admettant que la fonctionnalité concernée était déjà dans la version précédente). Quand l'utilisateur rencontre une régression, la nouvelle version marche moins bien que l'ancienne pour lui.
> Cela veut dire que même s'il reste des bugs, le kernel est déclaré comme
> stable, car Linus ne veut pas avoir plus de 8 RC pour une nouvelle version
> d'un kernel, et qu'en extrapolant les version 2.6.33.X ne sont que des versions
> 2.6.33 RC(8+X) ?
Je sais pas si c'est limité strictement à 8 rc pour Linux mais sortir une version sans bug connu n'est pas vraiment un but viable si tu veux espérer pouvoir ajouter des fonctionnalités.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # 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.
> monitoring ou c'est plus poussé (ce dont je suppose, mais je ne vois pas en quoi).
Ça peut être utilisé pour du monitoring mais je vois plutôt ça comme un outil de debugging et d'aide au réglage de performances.
> De plus il y a point de traçage statique et dynamique, quel sont les
> avantages/inconvénients de chacun ?
Les points de traçage statiques sont définis par le développeur du code. Il va instrumenter explicitement ce qu'il pense pouvoir être intéressant. Les points de traçages dynamiques sont définis par l'utilisateur du code. Cela permet donc d'oberver des choses auxquelles on n'a pas pensé a priori mais ça nécessite une meilleure compréhension du système à observer.
D'un point de vu non développeur, en gros, pour utiliser les points de traçage dynamiques, tu fais des echo 1 > /proc/sys/whatever/debug alors que pour le dynamiques, il faut dire explicitement ce que tu veux observer au niveau du code.
> Sinon autre chose, à propos des "régressions" : est-ce que c'est une
> manière élégante de dire "bugs" ?
Une régression est un bug qui n'existait pas dans la version précédente (en admettant que la fonctionnalité concernée était déjà dans la version précédente). Quand l'utilisateur rencontre une régression, la nouvelle version marche moins bien que l'ancienne pour lui.
> Cela veut dire que même s'il reste des bugs, le kernel est déclaré comme
> stable, car Linus ne veut pas avoir plus de 8 RC pour une nouvelle version
> d'un kernel, et qu'en extrapolant les version 2.6.33.X ne sont que des versions
> 2.6.33 RC(8+X) ?
Je sais pas si c'est limité strictement à 8 rc pour Linux mais sortir une version sans bug connu n'est pas vraiment un but viable si tu veux espérer pouvoir ajouter des fonctionnalités.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.