Chapitre 39 Stabilité

Sun permet fréquemment aux développeurs d'accéder en avance aux nouvelles technologies, ainsi qu'aux outils d'observation grâce auxquels les utilisateurs peuvent accepter bilatéralement les détails d'implémentation interne des logiciels utilisateur et de noyau. Malheureusement, les nouvelles technologies et les détails d'implémentation interne sont destinés à évoluer au fil de l'évolution et de la stabilisation des interfaces et des implémentations lorsque les logiciels sont mis à jour ou corrigés à l'aide d'un correctif. Sun documente les niveaux de stabilité des applications et des interfaces à l'aide d'un ensemble d'étiquettes décrites dans la page de manuel attributes(5) pour permettre de définir plus facilement les attentes des utilisateurs quant aux types de changement qui pourraient être mis en œuvre dans les diverses sortes de versions ultérieures.

Aucun attribut de sécurité ne décrit de manière appropriée l'ensemble arbitraire d'entités et de propriétés accessibles depuis un programme en D. Par conséquent, DTrace et le compilateur D intègrent des fonctions de calcul et de description dynamique des niveaux de stabilité des programmes en D que vous créez. Ce chapitre présente les fonctions de DTrace dédiées à la détermination de la stabilité du programme pour faciliter votre conception de programmes en D stables. Vous pouvez utiliser les fonctions de stabilité de DTrace pour rester informé des attributs de stabilité de vos programmes en D ou pour créer des erreurs de durée de compilation lorsque votre programme possède des dépendances d'interface indésirables.

Niveaux de stabilité

DTrace fournit deux types d'attribut de stabilité aux entités comme les variables intégrées, les fonctions et les sondes : un niveau de stabilité et une classe de dépendance architecturale. Le niveau de stabilité de DTrace vous aide à évaluer les risques lors du développement de scripts et d'outils basés sur DTrace en indiquant la probabilité selon laquelle une interface ou une entité de DTrace sera modifiée dans une version ou un correctif à venir. La classe de dépendance de DTrace vous indique si une interface est commune à toutes les plates-formes et à tous les processeurs Solaris ou si elle est associée à une architecture particulière comme les processeurs SPARC uniquement. Les deux types d'attribut utilisés pour décrire les interfaces peuvent varier indépendamment l'un de l'autre.

Les valeurs de stabilité utilisées par DTrace apparaissent dans la liste suivante du niveau de stabilité le plus faible au plus élevé. Les interfaces les plus stables peuvent être utilisées par tous les programmes en D et les applications en couches car Sun s'efforce de garantir leur compatibilité avec les versions mineures ultérieures. Les applications qui ne dépendent que des interfaces stables continueront de fonctionner de manière fiable sur les versions mineures ultérieures et ne seront pas interrompues par des correctifs intermédiaires. Les interfaces les moins stables permettent l'expérimentation, le prototypage, le réglage et le débogage de votre système actuel. Il est nécessaire, lors de leur utilisation, de savoir qu'elles peuvent s'avérer incompatibles avec les versions mineures ultérieures, de même qu'elles peuvent être supprimées ou remplacées.

Les valeurs de stabilité de DTrace permettent de comprendre plus facilement la stabilité des entités logicielles que vous observez, en plus de la stabilité des interfaces de DTrace elles-mêmes. Par conséquent, les valeurs de stabilité de DTrace vous indiquent également la probabilité suivant laquelle les changements correspondants sont requis au niveau de vos programmes en D et des outils en couches lors de la mise à jour ou de la modification de la pile logicielle observée.

Interne

L'interface est privée à DTrace et représente un détail d'implémentation de DTrace. Les interfaces internes peuvent changer dans les micro-versions et les versions mineures.

Privée

L'interface est privée à Sun. Elle constitue une interface dédiée aux autres produits Sun et n'est pas publiquement documentée pour pouvoir être utilisée par les clients et les ISV. Les interfaces privées peuvent subir des modifications dans les micro-versions et les versions mineures.

Obsolète

L'interface est prise en charge dans la version actuelle mais sa suppression, dans une prochaine version mineure, est programmée. Lorsque la prise en charge d'une interface est sur le point d'être interrompue, Sun essaye de le notifier à l'avance. Le compilateur D peut émettre des messages d'avertissement si vous tentez d'utiliser une interface obsolète.

Externe

L'interface est contrôlée par une entité autre que Sun. Sun, selon son appréciation exclusive, peut fournir des versions de mises à jour de ces interfaces, suceptibles d'être incompatibles, en fonction de leur disponibilité au niveau de l'entité de contrôle. Sun ne fait aucune déclaration sur la compatibilité source ou binaire des interfaces externes entre deux versions différentes. Les applications basées sur ces interfaces peuvent ne pas fonctionner dans les prochaines versions, y compris les correctifs qui contiennent des interfaces externes.

Instable

L'interface est fournie pour permettre aux développeurs d'accéder en avance aux nouvelles technologies et aux technologies en pleine évolution ou à un artefact d'implémentation essentiel à l'observation ou au débogage du comportement du système pour lequel une solution plus stable sera anticipée prochainement. Sun ne fait aucune déclaration sur la compatibilité source ou binaire des interfaces instables d'une version mineure à une autre.

Evolutive

L'interface peut éventuellement devenir standard ou stable mais reste en phase de transition. Sun mettra en œuvre les efforts raisonnables pour assurer la compatibilité avec les versions précédentes au fur et à mesure de l'évolution. Lorsque des modifications à compatibilité non ascendante s'imposent, elles sont implémentées dans le cadre d'une version mineure ou majeure. Les micro-versions ne contiendront pas, dans la mesure du possible, de telles modifications. Si de telles modifications s'imposent, elles seront documentées dans les notes de version de la version concernée, et dans la mesure du possible, Sun proposera une aide à la migration pour assurer la compatibilité binaire et le développement continu des programmes en D.

Stable

L'interface est une interface stabilisée sous le contrôle de Sun. Sun essayera de ne pas intégrer de modifications à compatibilité non ascendante à ces interfaces, notamment dans les versions mineures ou les micro-versions. En cas d'interruption de la prise en charge d'une interface stable, Sun essayera de le notifier. En outre, Ie niveau de stabilité bascule sur Obsolète.

Standard

L'interface est conforme au standard de l'industrie. La documentation correspondante de l'interface décrit le standard auquel l'interface se conforme. Les standards sont généralement contrôlés par un organisme de développement de standards. Par ailleurs, l'interface peut être modifiée en fonction des changements approuvés au niveau du standard observé. Ce niveau de stabilité peut également s'appliquer aux interfaces adoptées sans qu'une convention industrielle n'impose de standard formel. La prise en charge n'est fournie que pour les versions spécifiées d'un standard ; de ce fait, la prise en charge des versions ultérieures n'est pas garantie. Si l'organisme de développement de standards approuve une modification à compatibilité non ascendante d'une interface standard que Sun choisit de prendre en charge, Sun annoncera une stratégie de compatibilité et de migration.

Classes de dépendance

Depuis que Solaris et DTrace prennent en charge un grand nombre de processeurs et de plates-formes d'exploitation, DTrace étiquette également les interfaces avec une classe de dépendance vous indiquant si une interface est commune à toutes les plates-formes et à tous les processeurs Solaris ou si elle est associée à une architecture système particulière. La classe de dépendance est orthogonale aux niveaux de stabilité décrits précédemment. Par exemple, une interface DTrace peut être stable tout en n'étant prise en charge que sur les microprocesseurs SPARC ou instable mais commune à tous les systèmes Solaris. Les classes de dépendance de DTrace sont décrites dans la liste suivante, de la moins commune (c'est-à-dire la plus propre à une architecture particulière) à la plus commune (c'est-à-dire, commune à toutes les architectures).

Inconnue

L'interface intègre un ensemble inconnu de dépendances architecturales. DTrace ne connaît pas nécessairement les dépendances architecturales de toutes les entités, comme les types de données définis dans l'implémentation du système d'exploitation. L'étiquette Inconnue est généralement appliquée aux interfaces dont la stabilité est très faible et pour lesquelles il est impossible de calculer des dépendances. L'interface peut ne pas être disponible lorsque vous utilisez DTrace sur une architecture différente de celle que vous utilisez habituellement.

CPU

L'interface est spécifique au modèle de la CPU du système actuel. Vous pouvez utiliser l'option -v de l'utilitaire psrinfo(1M) pour afficher le modèle actuel de la CPU et les noms d'implémentation. Les interfaces possédant des dépendances de modèle de CPU peuvent ne pas être disponibles sur les autres implémentations des CPU, même si ces CPU exportent la même architecture ISA. Par exemple, une interface qui dépend de la CPU sur un microprocesseur UltraSPARC-III+ peut ne pas être disponible sur un microprocesseur UltraSPARC-II, même si les deux processeurs prennent en charge le jeu d'instructions SPARC.

Plate-forme

L'interface est spécifique à la plate-forme matérielle du système actuel. Une plate-forme associe généralement un ensemble de composants système et des caractéristiques architecturales comme un ensemble de modèles de CPU pris en charge à un nom système comme SUNW,Ultra-Enterprise-10000 . Vous pouvez afficher le nom de la plate-forme actuelle à l'aide de l'option uname(1) -i. L'interface peut ne pas être disponible sur les autres plates-formes matérielles.

Groupe

L'interface est spécifique au groupe de plates-formes matérielles du système actuel. Un groupe de plates-formes regroupe généralement un ensemble de plates-formes et les caractéristiques connexes sous un nom unique, comme sun4u. Vous pouvez afficher le nom du groupe de plates-formes actuel à l'aide de l'option uname(1) -m. L'interface est disponible sur les autres plates-formes du groupe de plates-formes mais peut ne pas l'être sur les plates-formes matérielles qui n'appartiennent pas à ce groupe.

ISA

L'interface est spécifique à l'architecture ISA prise en charge par les microprocesseurs de ce système. L'architecture ISA décrit les spécifications d'un logiciel dont l'exécution est possible sur le microprocesseur sans oublier les détails comme les instructions du langage d'assemblage et les enregistrements. Vous pouvez afficher les jeux d'instructions natives que le système prend en charge à l'aide de l'utilitaire isainfo(1). Il se peut que l'interface ne soit pas prise en charge sur les systèmes qui n'exportent aucun jeu d'instructions identique. Il est possible, par exemple, qu'une interface dépendante de l'architecture ISA sur un système Solaris SPARC ne soit pas prise en charge sur un système Solaris x86.

Commune

L'interface est commune à tous les systèmes Solaris indépendamment du matériel sous-jacent. Les programmes DTrace et les applications en couches qui ne dépendent que des interfaces communes sont exécutables et déployables sur d'autres systèmes Solaris intégrant les mêmes révisions Solaris et DTrace. La plupart des interfaces DTrace étant communes, vous pouvez les utiliser où que vous utilisiez Solaris.

Attributs d'interface

DTrace décrit les interfaces au moyen d'un triplet d'attributs consistant en deux niveaux de stabilité et en une classe de dépendance. Par convention, les attributs d'interface sont écrits dans l'ordre suivant et séparés par des barres obliques :

stabilité-noms / stabilité-noms / classe-dépendance

La stabilité des noms d'une interface décrit le niveau de stabilité associé au nom tel qu'il apparaît dans votre programme en D ou sur la ligne de commande dtrace(1M). Par exemple, la variable execname en langage D est un nom stable : Sun garantit que cet identificateur continuera d'être pris en charge dans vos programmes en D conformément aux règles décrites pour les interfaces stables ci-dessus.

La stabilité des données d'une interface se distingue de la stabilité associée au nom de l'interface. Ce niveau de stabilité décrit l'engagement de Sun à conserver les formats de données utilisés par l'interface, ainsi que la sémantique des données connexes. Par exemple, la variable pid en langage D est une interface stable : les ID de processus sont un concept stable dans Solaris et Sun garantit que la variable pid appartiendra au type pid_t, la sémantique étant définie sur l'ID de processus correspondant au thread ayant déclenché une sonde donnée conformément aux règles des interfaces stables.

La classe de dépendance d'une interface est distincte de la stabilité de son nom et de ses données et indique si l'interface est propre à la plate-forme d'exploitation ou au microprocesseur actuels.

DTrace et le compilateur D suivent les attributs de stabilité de toutes les entités d'interface de DTrace, y compris les fournisseurs, les descriptions de sonde, les variables en D, les fonctions en D, les types et les instructions de programme, comme nous allons brièvement l'étudier. Notez que les trois valeurs peuvent varier indépendamment les unes des autres. Par exemple, la variable curthread en langage D possède les attributs Stable/Privé/Commun : le nom de la variable est stable et il est commun à toutes les plates-formes d'exploitation Solaris mais cette variable permet d'accéder à un format de données privé qui s'avère être un artefact de l'implémentation du noyau Solaris. La plupart des variables en D possèdent les attributs Stable/Stable/Commun, comme les variables que vous définissez.

Rapports et calculs de stabilité

Le compilateur D exécute les calculs de stabilité de chaque description de sonde et instruction d'action dans vos programmes en D. Vous pouvez utiliser l'option dtrace -v pour afficher un rapport sur la stabilité de votre programme. L'exemple suivant utilise un programme écrit sur la ligne de commande :

# dtrace -v -n dtrace:::BEGIN'{exit(0);}'
dtrace: description 'dtrace:::BEGIN' matched 1 probe
Stability data for description dtrace:::BEGIN:
        Minimum probe description attributes
                Identifier Names: Evolving
                Data Semantics:   Evolving
                Dependency Class: Common
        Minimum probe statement attributes
                Identifier Names: Stable
                Data Semantics:   Stable
                Dependency Class: Common
CPU     ID                    FUNCTION:NAME
  0      1                           :BEGIN

Vous pouvez également souhaiter combiner l'option dtrace - v à l'option -e, afin d'indiquer à dtrace de compiler votre programme en D sans l'exécuter de manière à pouvoir déterminer la stabilité du programme sans devoir activer les sondes et exécuter votre programme. Voici un autre exemple de rapport de stabilité :

# dtrace -ev -n dtrace:::BEGIN'{trace(curthread->t_procp);}'
Stability data for description dtrace:::BEGIN:
        Minimum probe description attributes
                Identifier Names: Evolving
                Data Semantics:   Evolving
                Dependency Class: Common
        Minimum probe statement attributes
                Identifier Names: Stable
                Data Semantics:   Private
                Dependency Class: Common
#

Notez que dans notre nouveau programme, nous avons référencé la variable curthread en langage D, dont le nom est stable mais la sémantique des données privée (ce qui signifie qu'en les consultant, vous accédez aux détails d'implémentation privés du noyau). Ce statut se reflète désormais dans le rapport de stabilité du programme. Les attributs de stabilité dans le rapport du programme sont calculés en sélectionnant la classe et le niveau de stabilité minimale en dehors de la plage de valeurs correspondantes de chaque triplet d'attributs d'interface.

Les attributs de stabilité d'une description de sonde sont calculés à l'aide des attributs de stabilité minimale de tous les champs de description de sonde spécifiés conformément aux attributs publiés par le fournisseur. Les attributs des fournisseurs DTrace disponibles sont présentés dans le chapitre traitant de chaque fournisseur. Les fournisseurs de DTrace exportent un triplet d'attributs de stabilité pour chacun des quatre champs de description de toutes les sondes publiées par ce fournisseur. Par conséquent, la stabilité d'un nom de fournisseur peut être plus élevée que celle des sondes individuelles exportées. Par exemple, la description de la sonde :

fbt:::

indiquant que DTrace doit suivre les E/S de toutes les fonctions du noyau, possède une stabilité plus grande que la description de la sonde :

fbt:foo:bar:entry

qui nomme une fonction bar() interne spécifique dans le module du noyau foo. Par souci de simplicité, la plupart des fournisseurs utilisent un seul ensemble d'attributs pour toutes les valeurs individuelles nom:fonction:module émises. Les fournisseurs spécifient également des attributs pour le tableau args[], la stabilité des arguments de sonde variant d'un fournisseur à l'autre.

Si aucun champ de fournisseur n'est spécifié dans une description de sonde, cette description reçoit les attributs de stabilité Instable/Instable/Commun car elle peut aboutir à des sondes de fournisseurs qui n'existent pas encore lorsqu'utilisée sur une prochaine version de Solaris. Le cas échéant, Sun n'est pas en mesure de garantir la stabilité et le comportement à venir de son programme. Vous devez toujours spécifier explicitement le fournisseur lors de l'écriture des clauses de votre programme en D. En outre, chaque champ de description de sonde qui contient des caractères correspondant au modèle (reportez-vous au Chapitre4Structure de programme D) ou des variables de macro comme $1 (reportez-vous au Chapitre15Scripts) est traité comme s'il n'était pas spécifié car il est possible de développer ces modèles de description pour les adapter aux fournisseurs et aux sondes revus par Sun dans les versions ultérieures de DTrace et du système d'exploitation Solaris.

Les attributs de stabilité sont calculés pour la plupart des instructions en langage D en s'appuyant sur la classe et la stabilité minimale des entités figurant dans l'instruction. Par exemple, les entités en langage D ci-après possèdent les attributs suivants :

Si vous écrivez l'instruction de programme en D suivante :

x += curthread->t_pri;

les attributs résultant de l'instruction sont Stable/Privé/Commun, les attributs minimaux associés aux opérandes curthread et x. La stabilité d'une expression est calculée à l'aide des attributs de stabilité minimale de chaque opérande.

Toutes les variables en D que vous définissez dans votre programme reçoivent automatiquement les attributs Stable/Stable/Commun. Par ailleurs, les attributs Stable/Stable/Commun sont affectés de manière implicite aux opérateurs en D et à la grammaire du langage D. Les attributs Privé/Privé/Inconnu sont toujours attribués aux références aux symboles du noyau utilisant l'opérateur (`) car ils reflètent les artefacts d'implémentation. Les types que vous définissez dans le code source de vos programmes en D, et plus particulièrement celui qui est associé à l'espace de noms de types C et D, reçoivent les attributs Stable/Stable/Commun. Les types définis dans l'implémentation du système d'exploitation et fournis par d'autres espaces de noms reçoivent les attributs Privé/Privé/Inconnu. L'opérateur de stabilisation de type en langage D intègre une expression dont les attributs de stabilité correspondent aux valeurs minimales des attributs de l'expression d'entrée et des attributs du type de sortie stabilisé.

Si vous utilisez le préprocesseur C pour intégrer des fichiers d'en-tête système en C, ces types sont associés à l'espace de noms de type C et reçoivent les attributs Stable/Stable/Commun, le compilateur D n'ayant pas d'autre choix que de supposer que vous assumez la responsabilité de ces déclarations. Vous pouvez toutefois vous tromper sur la stabilité de votre programme si vous utilisez le préprocesseur C pour intégrer un fichier d'en-tête contenant des artefacts d'implémentation. Vous devez toujours consulter la documentation correspondant aux fichiers d'en-tête que vous intégrez pour déterminer les niveaux de stabilité appropriés.

Mise en œuvre de la stabilité

Lors du développement d'un script ou d'un outil en couches DTrace, vous souhaiterez peut-être identifier la source propre aux problèmes de stabilité ou vérifier que votre programme dispose de l'ensemble des attributs de stabilité souhaités. Vous pouvez utiliser l'option dtrace -x amin=attributes pour contraindre le compilateur en D à créer une erreur lorsque des calculs d'attributs engendrent un triplet d'attributs inférieur aux valeurs minimales que vous spécifiez sur la ligne de commande. L'exemple suivant présente l'utilisation de -x amin à l'aide d'un snippet de la source du programme en D. Notez que les attributs sont spécifiés à l'aide de trois étiquettes délimitées par / dans l'ordre usuel.

# dtrace -x amin=Evolving/Evolving/Common \
    -ev -n dtrace:::BEGIN'{trace(curthread->t_procp);}'
dtrace: invalid probe specifier dtrace:::BEGIN{trace(curthread->t_procp);}: \
    in action list: attributes for scalar curthread (Stable/Private/Common) \
    are less than predefined minimum
#