Kapitel 39 Stabilität

Sun bietet Entwicklern häufig frühzeitigen Zugang zu neuen Technologien und Beobachtungstools, die den Benutzern einen Einblick in die internen Implementierungsdetails von Benutzer- wie Kernel-Software ermöglichen. Leider unterliegen neue Technologien und interne Implementierungsdetails naturgemäß ständigen Veränderungen aufgrund der Weiterentwicklung und Ausreifung von Schnittstellen und Implementierungen, die in Form von Aktualisierungen und Patches der Software bereitgestellt werden. Die verschiedenen Anwendungs- und Schnittstellenstabilitätsstufen dokumentiert Sun anhand der in der Manpage attributes(5) beschriebenen Bezeichnungen, die den Benutzern eine Vorstellung der in künftigen Versionen zu erwartenden Änderungen geben sollen.

Die beliebige Sammlung von Größen und Diensten, auf die über ein D-Programm zugegriffen werden kann, lässt sich mit einem einzigen Stabilitätsattribut nicht angemessen beschreiben. Deshalb enthalten DTrace und der D-Compiler Leistungsmerkmale, die für eine dynamische Berechnung und Beschreibung der Stabilitätsstufen der von Ihnen erstellten D-Programme sorgen. Dieses Kapitel befasst sich mit den DTrace-Leistungsmerkmalen für die Ermittlung der Programmstabilität, die Ihnen dabei helfen, stabile D-Programme zu entwerfen. Sie können die DTrace-Stabilitätsleistungsmerkmale dazu nutzen, sich über die Stabilitätsattribute Ihrer D-Programme zu informieren oder, für den Fall, dass ein Programm unerwünschte Schnittstellenabhängigkeiten aufweist, Kompilierungszeitfehler zu erzeugen.

Stabilitätsstufen

DTrace stellt zwei Arten von Stabilitätsattributen für Größen wie integrierte Variablen, Funktionen und Prüfpunkte bereit: eine Stabilitätsstufe und eine architektonische Abhängigkeitsklasse. Die DTrace-Stabilitätsstufe gibt an, wie wahrscheinlich es ist, dass eine Schnittstelle oder DTrace-Größe in einer künftigen Version oder einem Patch geändert wird, und unterstützt Sie somit bei der Risikobewertung für Skripten und Tools, die Sie auf der Grundlage von DTrace entwickeln. Die DTrace-Abhängigkeitsklasse gibt Aufschluss darüber, ob eine Schnittstelle auf alle Solaris-Plattformen und Prozessoren oder nur auf eine bestimmte Architektur wie beispielsweise SPARC-Prozessoren zutrifft. Die zwei Attributarten zur Beschreibung von Schnittstellen können unabhängig voneinander variieren.

In der folgenden Liste sind die in DTrace verwendeten Stabilitätswerte in aufsteigender Reihenfolge, also von der niedrigsten zur höchsten Stabilität, aufgeführt. Die stabileren Schnittstellen können von allen D-Programmen und mehrschichtigen Anwendungen verwendet werden. Sun bemüht sich, zu gewährleisten, dass diese auch in künftigen Unterversionen weiterhin funktionieren. An der fehlerfreien Ausführung von Anwendungen, die nur von stabilen (Stable) Schnittstellen abhängen, sollten weder künftige Unterversionen noch Zwischen-Patches etwas ändern. Mit den weniger stabilen Schnittstellen bietet sich die Möglichkeit zum Experimentieren, Erstellen von Prototypen, Abstimmen und Debuggen auf aktuellen Systemen. Sie sollten allerdings in dem Bewusstsein eingesetzt werden, dass sie in künftigen Unterversionen inkompatibel oder gar verworfen oder aber durch Alternativen ersetzt werden könnten.

Die DTrace-Stabilitätswerte helfen Ihnen außerdem, neben der Stabilität der DTrace-Schnittstellen selbst auch die Stabilität der unter Beobachtung stehenden Softwaregrößen zu verstehen. Folglich lässt sich aus den DTrace-Stabilitätswerten auch schließen, wie wahrscheinlich es ist, dass Ihre D-Programme und mehrschichtigen Tools bei einem Upgrade oder einer Änderung des beobachteten Software-Stacks ebenfalls entsprechend geändert werden müssen.

Internal

Diese DTrace vorbehaltene Schnittstelle stellt ein Implementierungsdetail von DTrace dar. Schnittstellen des Typs „Internal“ können sich in Unter- oder Micro-Versionen ändern.

Private

Diese Sun vorbehaltene Schnittstelle wurde zur Verwendung durch andere Sun-Produkte entwickelt und noch nicht für den Gebrauch durch Kunden und ISVs öffentlich dokumentiert. Schnittstellen des Typs „Private“ können sich in Unter- oder Micro-Versionen ändern.

Obsolete

Die Schnittstelle wird in der aktuellen Version unterstützt, aber voraussichtlich in einer künftigen Unterversion entfernt. In der Regel wird die geplante Beendigung der Unterstützung einer Schnittstelle von Sun frühzeitig angekündigt. Bei einem Versuch, eine als „Obsolete“ gekennzeichnete Schnittstelle zu verwenden, gibt der D-Compiler u. U. eine Warnmeldung aus.

External

Die Schnittstelle wird von einem Drittanbieter kontrolliert, der·mit Sun nicht assoziiert ist. Sun kann im Rahmen eines Releases nach eigenem Ermessen je nach Verfügbarkeit vom Drittanbieter aktualisierte und möglicherweise inkompatible Versionen solcher Schnittstellen liefern. Sun gewährleistet in Bezug auf Schnittstellen des Typs „External“ weder eine Quell- noch Binärkompatibilität zwischen zwei beliebigen Versionen. Auf diesen Schnittstellen basierende Anwendungen sowie Patches, die externe Schnittstellen enthalten, funktionieren in künftigen Versionen möglicherweise nicht.

Unstable

Die Schnittstelle wird mit der Absicht bereitgestellt, Entwicklern einen frühzeitigen Zugang zu neuen oder schnell veränderlichen Technologien oder Implementierungsartefakten zu ermöglichen, die von zentraler Bedeutung für die Beobachtung oder das Debuggen des Systemverhaltens sind und für die in Zukunft eine stabilere Lösung geboten wird. Sun gewährleistet für Schnittstellen des Typs „Unstable“ weder Quell- noch Binärkompatibilität zwischen zwei aufeinander folgenden Unterversionen.

Evolving

Die Schnittstelle kann bald „Standard“ oder „Stable“ werden, befindet sich aber derzeit noch im Übergang. Sun bemüht sich, auch während der Fortentwicklung, eine Kompatibilität mit vorigen Versionen zu sichern. Wenn nicht aufwärtskompatible Änderungen erforderlich sind, werden diese in Unter- und Hauptversionen vorgenommen. In Micro-Versionen werden derartige Änderungen so weit wie möglich vermieden. Sollte eine solche Änderung notwendig sein, wird sie in den Versionshinweisen der betreffenden Version dokumentiert und, sofern machbar, stellt Sun Migrationshilfen bereit, die sowohl für Binärkompatibilität als auch eine unterbrechungsfreie D-Programmentwicklung sorgen.

Stable

Die Schnittstelle ist ausgereift und unterliegt der Kontrolle durch Sun. Sun bemüht sich, insbesondere in Unter- oder Micro-Versionen, nicht aufwärtskompatible Änderungen dieser Schnittstellen zu vermeiden. Falls die Unterstützung einer Schnittstelle des Typs „Stable“ beendet werden muss, kündigt Sun dies wenn möglich an, und die Stabilitätsstufe ändert sich in „Obsolete“.

Standard

Die Schnittstelle entspricht einem Industriestandard. Die Dokumentation der Schnittstelle beschreibt den Standard, den die Schnittstelle erfüllt. Standards unterstehen naturgemäß der Kontrolle einer Standardisierungsorganisation. Änderungen an der Interface sind im Einklang mit genehmigten Änderungen des jeweiligen Standards zulässig. Diese Stabilitätsstufe gelten mitunter auch für Schnittstellen, die ohne formalen Standard aus einem Industrieabkommen übernommen wurden. Unterstützung wird nur für die angegebenen Versionen eines Standards geboten; eine Unterstützung für spätere Versionen ist nicht garantiert. Genehmigt die Standardisierungsorganisation eine nicht aufwärtskompatible Änderung einer Schnittstelle des Typs „Standard“, die Sun zu unterstützen entscheidet, kündet Sun eine Strategie für Kompatibilität und Migration an.

Abhängigkeitsklassen

Angesichts der zahlreichen Betriebsplattformen und Prozessoren, die Solaris und DTrace unterstützen, kennzeichnet DTrace Schnittstellen außerdem mit einer Abhängigkeitsklasse, die Aufschluss darüber gibt, ob eine Schnittstelle für alle Solaris-Plattformen und Prozessoren oder nur für eine bestimmte Systemarchitektur Gültigkeit besitzt. Die Abhängigkeitsklassen stehen in keinem linearen Zusammenhang mit den bereits besprochenen Stabilitätsstufen. So kann eine DTrace-Schnittstelle beispielsweise „Stable“ sein, aber nur auf SPARC-Mikroprozessoren unterstützt werden oder „Unstable“, aber für alle Solaris-Systeme zutreffen. Die DTrace-Abhängigkeitsklassen sind in der folgenden Liste von der am wenigsten allgemeingültigen (d. h. der am meisten für eine bestimmte Architektur spezifischen) bis zur allen Architekturen gemeinsamen Schnittstelle aufgeführt.

Unknown

Die Abhängigkeit der Schnittstelle von Architekturen ist unbekannt. DTrace kennt nicht unbedingt die Architekturabhängigkeit aller Größen wie beispielsweise von Datentypen, die in der Betriebssystemimplementierung definiert sind. Als „Unknown“ werden in der Regel Schnittstellen sehr geringer Stabilität gekennzeichnet, für die keine Abhängigkeiten berechnet werden können. Die Schnittstelle ist möglicherweise nicht verfügbar, wenn Sie DTrace auf einer beliebigen anderen als der derzeit verwendeten Architektur ausführen.

CPU

Die Schnittstelle ist spezifisch auf das CPU-Modell des aktuellen Systems ausgerichtet. Mit dem Dienstprogramm psrinfo(1M) und der Option -v lassen sich die Bezeichnungen des aktuellen CPU-Modells und der Implementierung anzeigen. Schnittstellen mit CPU-Modellabhängigkeiten stehen auf anderen CPU-Implementierungen möglicherweise auch dann nicht zur Verfügung, wenn diese CPUs dieselbe Befehlssatzarchitektur (ISA) exportieren. So steht beispielsweise eine CPU-abhängige Schnittstelle auf einem UltraSPARC-III+-Mikroprozessor auf UltraSPARC-II nicht zur Verfügung, obwohl beide Prozessoren den SPARC-Befehlssatz unterstützen.

Platform

Die Schnittstelle ist spezifisch auf die Hardware-Plattform des aktuellen Systems ausgerichtet. Eine Plattform verbindet eine Gruppe von Systemkomponenten und architektonischen Merkmalen wie zum Beispiel einen Satz unterstützter CPU-Modelle mit einem Systemnamen wie SUNW,Ultra-Enterprise-10000 . Den aktuellen Plattformnamen rufen Sie mit uname(1) und der Option -i ab. Die Schnittstelle steht auf anderen Hardware-Plattformen möglicherweise nicht zur Verfügung.

Group

Die Schnittstelle ist spezifisch auf die Hardware-Plattformgruppe des aktuellen Systems ausgerichtet. Eine Plattformgruppe vereint eine Menge von Plattformen mit ähnlichen Merkmalen unter einem einzigen Namen, wie beispielsweise sun4u. Den Namen der aktuellen Plattformgruppe rufen Sie mit uname(1) und der Option -m ab. Die Schnittstelle ist auf anderen Plattformen derselben Gruppe verfügbar, auf Hardware-Plattformen anderer Gruppen möglicherweise nicht.

ISA

Die Schnittstelle ist spezifisch auf die Befehlssatzarchitektur (ISA) ausgerichtet, die von den Prozessoren dieses Systems unterstützt wird. Die ISA beschreibt eine Spezifikation der auf dem Prozessor ausführbaren Software, einschließlich der Assemblersprachen-Anweisungen, Register und anderer Details. Mit dem Dienstprogramm isainfo(1) rufen Sie die von dem System unterstützten nativen Befehlssätze ab. Die Schnittstelle wird auf Systemen, die nur andere Befehlssätze exportieren, möglicherweise nicht unterstützt. So wird beispielsweise eine ISA-abhängige Schnittstelle auf einem Solaris SPARC-System auf einem Solaris x86-System nicht unbedingt unterstützt.

Common

Die Schnittstelle ist allen Solaris-Systemen unabhängig von der zugrunde liegenden Hardware gemeinsam. DTrace-Programme und mehrschichtige Anwendungen, die nur von Schnittstellen des Typs „Common“ abhängen, können auf anderen Solaris-Systemen mit derselben Solaris- und DTrace-Version ausgeführt und bereitgestellt werden. Die meisten DTrace-Schnittstellen sind „Common“ und können überall dort eingesetzt werden, wo Solaris läuft.

Schnittstellenattribute

DTrace beschreibt Schnittstellen anhand einer Dreiergruppe von Attributen, die aus zwei Stabilitätswerten und einer Abhängigkeitsklasse besteht. Vereinbarungsgemäß werden die Schnittstellenattribute in folgender Reihenfolge und durch Schrägstriche getrennt wiedergegeben:

Namensstabilität / Datenstabilität / Abhängigkeitsklasse

Die Namensstabilität einer Schnittstelle bezeichnet die Stabilitätsstufe ihres Namens, wie er im D-Programm oder in der dtrace(1M)-Befehlszeile erscheint. Die D-Variable execname zum Beispiel weist einen stabilen (Stable) Namen auf: Sun garantiert, dass dieser Name gemäß den zuvor für Schnittstellen des Typs „Stable“ aufgeführten Regeln in Ihren D-Programmen weiterhin unterstützt wird.

Die Datenstabilität einer Schnittstelle unterscheidet sich von der Stabilität ihres Namens. Diese Stabilitätsbezeichnung drückt das Bemühen seitens Sun aus, die von der Schnittstelle verwendeten Datenformate und die eventuell entsprechende Datensemantik beizubehalten. Die D-Variable pid zum Beispiel ist eine stabile (Stable) Schnittstelle: Prozess-IDs stellen in Solaris ein stabiles Konzept dar und Sun garantiert, dass die Variable pid im Einklang mit den Regeln für Schnittstellen des Typs „Stable“ den Typ pid_t mit der auf die Prozess-ID des Threads, der einen bestimmten Prüfpunkt ausgelöst hat, gesetzten Semantik behält.

Die Abhängigkeitsklasse einer Schnittstelle unterscheidet sich von ihrer Namens- und Datenstabilität und gibt an, ob die Schnittstelle nur für die aktuelle Betriebsplattform oder den aktuellen Prozessor Gültigkeit besitzt.

Wie wir gleich sehen werden, kennzeichnen DTrace und der D-Compiler die Stabilitätsattribute sämtlicher DTrace-Schnittstellengrößen. Dazu gehören Provider, Prüfpunktbeschreibungen, D-Variablen, D-Funktionen, Typen und Programmanweisungen selbst. Beachten Sie, dass sich die drei Werte unabhängig voneinander verhalten. Beispielsweise besitzt die D-Variable curthread die Attribute Stable/Private/Common: Der Variablenname ist „Stable“ und allen Solaris-Betriebsplattformen gemeinsam („Common“), aber die Variable bietet Zugang zu einem privaten („Private“) Datenformat, das ein Produkt der Solaris-Kernelimplementierung ist. Die meisten D-Variablen besitzen die Attribute Stable/Stable/Common, so wie auch die von Ihnen selbst definierten Variablen.

Stabilitätsberechnung und -berichte

Der D-Compiler stellt für jede Prüfpunktbeschreibung und Aktionsanweisung in Ihren D-Programmen Stabilitätsberechnungen an. Mit der dtrace-Option -v erhalten Sie einen Bericht über die Stabilität eines Programms. Das folgende Beispiel zeigt ein in der Befehlszeile geschriebenes Programm:

# 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

Außerdem lässt sich die dtrace-Option -v mit der Option -e kombinieren, wodurch dtrace das D-Programm zwar kompiliert, aber nicht ausführt und Sie die Programmstabilität ermitteln können, ohne dafür Prüfpunkte aktivieren und das Programm ausführen zu müssen. Ein weiteres Beispiel für einen Stabilitätsbericht:

# 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
#

Beachten Sie, dass in dem neuen Programm die D-Variable curthread referenziert wird, deren Namensstabilität „Stable“, ihre Datensemantik jedoch „Private“ ist (d. h. Sie greifen auf private Implementierungsdetails des Kernels zu). Dieser Zustand wird im Stabilitätsbericht des Programms wiedergegeben. Zur Berechnung der Stabilitätsattribute im Programmbericht werden aus den entsprechenden Werten für jede Dreiergruppe an Schnittstellenattributen die niedrigste Stabilitätsstufe und Klasse ausgewählt.

Stabilitätsattribute für Prüfpunktbeschreibungen errechnen sich aus den geringsten Stabilitätsattributen aller angegebenen Prüfpunktbeschreibungsfelder entsprechend den vom Provider veröffentlichten Attributen. Die Attribute der verfügbaren DTrace-Provider sind in den Kapiteln über die einzelnen Provider aufgeführt. DTrace-Provider exportieren für jedes der vier Beschreibungsfelder aller von diesem Provider veröffentlichten Prüfpunkte eine Dreiergruppe von Stabilitätsattributen. Ein Providername weist deshalb u. U. eine höhere Stabilität auf als die einzelnen Prüfpunkte, die er exportiert. So hat zum Beispiel die Prüfpunktbeschreibung:

fbt:::

(sie gibt an, dass DTrace den Eintritt in und die Rückkehr aus allen Kernelfunktionen verfolgen soll) eine größere Stabilität als die Prüfpunktbeschreibung:

fbt:foo:bar:entry

die eine spezifische interne bar()-Funktion im Kernelmodul foo angibt. Der Einfachheit halber versehen die meisten Provider alle von ihnen veröffentlichten Modul:Funktion:Name-Werte mit nur einem Attributsatz. Außerdem geben Provider Attribute für den Vektor args[] bekannt, denn die Stabilität aller Prüfpunktargumente variiert von Provider zu Provider.

Sollte das Providerfeld in einer Prüfpunktbeschreibung nicht angegeben sein, werden der Beschreibung die Stabilitätsattribute Unstable/Unstable/Common zugewiesen, da die Beschreibung beim Einsatz unter einer künftigen Solaris-Version möglicherweise auf Prüfpunkte von Providern zutrifft, die bisher noch nicht existieren. Über die Zukunft des Programms im Hinblick auf Stabilität und Verhalten kann Sun keine Garantien aussprechen. Provider sollten beim Schreiben von D-Programmklauseln stets explizit angegeben werden. Darüber hinaus werden Prüfpunktbeschreibungsfelder, die Mustervergleichszeichen (siehe Kapitel 4D-Programmstruktur) oder Makrovariablen wie $ 15 (siehe Kapitel 15Scripting) enthalten, als unbestimmte Felder behandelt, da diese Beschreibungsmuster auf Provider oder Prüfpunkte zutreffen könnten, die Sun in künftigen Versionen von DTrace oder des Betriebssystems Solaris herausgeben kann.

Für die meisten D-Anweisungen errechnen sich die Stabilitätsattribute aus der niedrigsten Stabilität und Klasse der Größen in der Anweisung. Die folgenden D-Größen besitzen beispielsweise diese Attribute:

Wenn Sie die folgende D-Programmanweisung schreiben:

x += curthread->t_pri;

erhalten die Anweisungen die Attribute Stable/Private/Common, also die niedrigsten Attribute der Operanden curthread und x. Die Stabilität eines Ausdrucks errechnet sich aus den geringsten Stabilitätsattributen aller Operanden.

Allen D-Variablen, die Sie in einem Programm definieren, werden automatisch die Attribute Stable/Stable/Common zugewiesen. Außerdem werden der D-Grammatik sowie den D-Operatoren implizit die Attribute Stable/Stable/Common zugewiesen. Verweise auf Kernelsymbole anhand des Backquote-Operators (`) stellen Artefakte der Implementierung dar und erhalten als solche stets die Attribute Private/Private/Unknown. Den in Ihrem D-Programmquellcode definierten Typen, insbesondere solchen aus Namensräumen für C- und D-Typen, werden die Attribute Stable/Stable/Common zugewiesen. Typen, die in der Betriebssystemimplementierung definiert sind und von Namensräumen für andere Typen bereitgestellt werden, erhalten die Attribute Private/Private/Unknown. Der D-Operator für die explizite Typumwandlung ergibt einen Ausdruck, dessen Stabilitätsattribute sich aus den niedrigsten Attributen des Eingangsausdrucks und den Attributen des explizit umgewandelten Ausgangstyps ableiten.

Wenn Sie mit dem C-Preprozessor C-Systemdefinitionsdateien aufnehmen, werden diese Typen dem Namensraum für C-Typen zugeordnet und erhalten die Attribute Stable/Stable/Common, da der D-Compiler davon ausgehen muss, dass Sie die Verantwortung für diese Deklarationen übernehmen. Folglich ist es denkbar, dass Sie sich im Hinblick auf die Stabilität Ihrer Programme selbst in die Irre führen, wenn Sie den C-Preprozessor verwenden, um eine Definitionsdatei mit Implementierungsartefakten aufzunehmen. Um die richtigen Stabilitätsstufen zu bestimmen, sollten Sie stets die Dokumentation zu den verwendeten Definitionsdateien zu Rate ziehen.

Erzwingen einer Stabilität

Beim Schreiben von DTrace-Skripten oder mehrschichtigen Tools kann es hilfreich sein, die spezifische Ursache von Stabilitätsproblemen zu ermitteln oder sicherzustellen, dass das Programm eine bestimmte Gruppe von Stabilitätsattributen erhält. Über die Option dtrace -x amin=Attribute können Sie den D-Compiler dazu bringen, einen Fehler zu generieren, wenn eine der Attributberechnungen eine Dreiergruppe ergibt, die geringer ist, als die von Ihnen in der Befehlszeile angegebenen Mindestwerte. Das folgende Beispiel veranschaulicht die Wirkung von -x amin bei einem D-Programmfragment. Beachten Sie, dass die Attribute durch drei mit / voneinander getrennte Bezeichnungen in der üblichen Reihenfolge wiedergegeben werden.

# 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
#