Wiedergabe und Präsentation von tracebasierten Implementierungssichten über den Linuxkern

Inhaltsverzeichnis

1 Einleitung
1.1. Motivation
1.2. Beschreibung der Aufgabenstellung
1.3. Gliederung der Arbeit

2 Grundlagen
2.1. Specification
2.1.1. XML
2.1.2. SVG
2.1.2.1. Aufbau von SVG Dateien
2.1.2.2. Grafische Primitive
2.1.2.3. Text
2.1.2.4. Elemente zur Strukturierung
2.1.2.5. Sonstige Elemente und Funktionen von SVG
2.1.2.6. Beispiele
2.1.3. XSL Transformations (XSLT)
2.1.3.1. Aufbau und Funktionsweise von XSLT Stylesheets
2.1.3.2. Beispiel
2.1.4. XML Metadata Interchange Format (XMI)
2.2. Gathering
2.2.1. KProbes, JProbes und Kretprobes
2.2.2. Systemtap
2.2.2.1. Funktionsweise von Systemtap
2.2.2.2. Welche Tracingdaten können durch Systemtap Probes gesammelt werden ?
2.2.2.3. Systemtap Skriptsprache
2.2.2.3.1. Definition von Systemtap Probes
2.2.2.3.2. Definition von Hilfsfunktionen
2.2.2.3.3. Ausgabe durch Systemtap
2.2.2.3.4. Beispielskript
2.3. Analyzing-and-Visualizing
2.3.1. LTT
2.3.2. LTTng und LTTV
2.3.2.1. LTTV Viewer
2.3.3. Verbindung von Systemtap und LTTV Viewer

3 Anforderungsanalyse und Auswahl der Werkzeuge
3.1. Specification
3.1.1. Beschreibung der Schablonen
3.1.2. Erstellung der Schablonen
3.1.3. Transformation der Schablonen
3.1.4. Zuordnung der Schablonen, Transformationen und des Quellcodes zu den Tracingevents
3.2. Gathering
3.3. Analyzing-and-Visualizing

4 Prototypischer Entwurf und Implementierung des Toolkits
4.1. Specification
4.1.1. Möglichst automatische Erstellung der Systemtap Probes sowie der LTTV Eventdefinitionen
4.1.1.1. Finden des Quellcodes der zu instrumentierenden Kernel- und Kernelmodulfunktionen
4.1.1.2. Auslesen der Parameter- und Rückgabetypen sowie der Parameternamen der zu instrumentierenden Funktionen aus deren Quellcode
4.1.1.3. Weiterverarbeitung der Daten im XML Format
4.1.1.4. Erstellung der Systemtap Probes
4.1.1.5. Erstellung der LTTV Eventdefinitionen
4.1.2. Zuordnung und Erstellung der SVG Schablonen sowie der dazugehörigen XSLT Stylesheets
4.2. Gathering
4.3. Analyzing-and-Visualizing
4.3.1. Erstellung von Modulen für den LTTV Viewer
4.3.2. Finden aller einem Event zugeordneten Schablonen
4.3.3. Anzeige des Quellcodes
4.3.4. Darstellung der SVG Dateien durch das LTTV Modul
4.3.5. Einsatz und Ergebnisse des neuen LTTV Moduls
4.4. Verwendung von höherwertigen Werkzeugen zur Erstellung von SVG Schablonen und XSLT Transformationen
4.4.1. Erstellung der SVG Dateien durch einen SVG Editor
4.4.2. Verwendung von UML Diagrammen als Grundlage zur Erstellung von SVG Schablonen sowie der dazugehörigen XSLT Stylesheets am Beispiel von Sequenzdiagrammen
4.4.2.1. Erstellung der UML Diagramme
4.4.2.2. Konvertierung der UML Diagramme nach SVG
4.4.2.2.1. Aufbau von uml2svg.xsl (für Sequenzdiagramme relevanter Anteil)
4.4.2.2.2. Erweiterung von uml2svg.xsl
4.4.2.3. Automatische Erstellung der zu den SVG Dateien passenden XSLT Transformationen

5 Prototypisches Testen am Beispiel des USB Maustreibers „usbmouse“
5.1. USB Grundlagen
5.2. Input Subsystem
5.3. USB Maustreiber „usbmouse“
5.4. Instrumentierung des Maustreibers und Visualisierung der Tracingdaten
5.5. Ergebnisse

6 Filterung der Tracingdaten
6.1. Filterung durch Verwendung des Systemtap Target PID Mechanismus
6.2. Dynamische Filterung anhand mehrerer PIDs

7 Anwendungsbeispiel: Ermittlung und Visualisierung der Zustände von Filedeskriptor-Tabellen
7.1. Aufgabenstellung
7.2. Filedeskriptor Tabellen und Openfiletable im realen System
7.3. Erstellung der Systemtap Skripte
7.4. Erstellung der SVG Schablonen und der XSLT Stylesheets
7.5. Erstellung der Prozesse
7.6. Ergebnisse

8 Zusammenfassung und Ausblick
8.1. Zusammenfassung
8.2. Ausblick

9 Quellen

10 Inhaltsverzeichnis

11 Stichwortverzeichnis

12 Abbildungsverzeichnis

13 Tabellenverzeichnis

14 Verzeichnis der Listings

1 Einleitung

1.1. Motivation

Aufgrund der stetig steigenden Komplexität des Linuxkerns [18] (siehe Abbildung 1-1 und Abbildung 1-2) erlangt dessen Analyse durch Tracingtools eine immer größere Bedeutung für die Fehlersuche und für das Verständnis des Systemverhaltens. Zu diesem Zweck wurden zahlreiche Tracingmechanismenund Tracingtools entwickelt. Die Palette reicht dabei vom einfachen „printk()“ Mechanismus, mit dessen Hilfe ein beliebiger, formatierter String in das Syslog geschrieben werden kann, bis hin zu komplexen Toolpaketen, wie z.B. LTTng + LTTV [3], die Tracingdaten durch einen Kernelpatchabgreifen und Programme zur Analyse und Visualisierungder Tracingdaten enthalten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1-1: Wachstumder komprimierten tar Datei der Linux Kernelquellen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1-2: Wachstum der Subsysteme(Development Releases) bezüglich der Anzahl der Zeilen des Quellcodes (ohne Leerzeilen und Kommentare).

Ein Teil der Tracingtools wie z.B. LTTng + LTTV ist in der Lage, Tracingdaten grafisch aufzubereiten. Diese grafischen Darstellungen beschränken sich jedoch auf die Ausgabe von Analyseergebnissenals Graphensowie die Anordnung der aufgetretenen Tracingevents auf einer Zeitachse. Die Visualisierung ist dabei stets fest vorgegeben, kann also nicht vom Benutzer beeinflusst werden. Obwohl eine solche Darstellung von Tracingdaten hilfreich sein kann, ist diese jedoch nur von begrenztem Nutzen, insbesondere für die Betriebssystemausbildung, da man dort andere Sichten als die vorgegebenen präsentieren möchte. Wesentlich besser wäre ein flexibles Analyse- und Visualisierungstool, das es dem Benutzer ermöglicht, mehrere alternative Visualisierungen zu definieren und den Tracingevents zuzuordnen. Außerdem wäre es wünschenswert, den Tracingevents ergänzende Informationen wie z.B. den entsprechenden Kernel- bzw. Kernelmodulquellcodezuordnen und diese anzeigen zu können.

Zur Realisierung dieser neuen Aspekte müssen u.a. Spezifikationssprachenzur Definition der interessierenden Tracingevents mit ihren Eventattributen, der Visualisierungen und zur Definition der Zuordnungder Visualisierungen sowie der ergänzenden Informationen zu den Tracingevents entwickelt werden. Dabei bietet es sich an, möglichst alle Spezifikationenin XML[60], einer Markupsprachezur Beschreibung strukturierter Daten in Form von Textdateien, zu definieren, da XML heute schon eine wichtige Rolle beim Datenaustausch über das Web spielt und sich immer mehr durchsetzt [8]. Man kann davon ausgehen, dass HTML einmal durch XML ersetzt wird. Aus diesem Grund können Kenntnisse des Benutzers bezüglich XML vorausgesetzt werden. Außerdem vereinfacht dies die Verarbeitung der Daten, da dann die bekannten XML Standardwerkzeugewie z.B. XML Parser und XSLT Stylesheetsverwendet werden können.

1.2. Beschreibung der Aufgabenstellung

Ziel dieser Arbeit ist es, ein generisches System prototypisch zu entwickeln, das durch das Zusammenspiel verschiedener Werkzeuge, Tracingdaten des Linuxkernels und seiner Module sammeln und diese unter Verwendung von benutzerdefinierten Visualisierungsschablonenund Transformationsregelnvisualisieren kann. Außerdem soll zu jedem Tracingevent der entsprechende Kernel- bzw. Kernelmodulquellcodegefunden und angezeigt werden.

Das System soll es ermöglichen, benutzerdefinierte Abläufe, Zusammenhänge und Implementierungssichtenin Abhängigkeit der gesammelten Tracingdaten darstellen zu können. Die Visualisierung basiert dabei auf der Idee, dass der Benutzer Visualisierungsschablonen und Transformationsregeln definieren kann. Wird im Traceviewerein Tracingevent vom Benutzer ausgewählt, soll eine dem Tracingevent zugeordnete Visualisierungsschablone ausgewählt, durch die dazugehörigen Transformationsregeln in Abhängigkeit der Eventdaten verändert und schließlich angezeigt werden.

Die Werkzeuge des zu entwickelnden Systems lassen sich in drei Gruppen einteilen; jede Werkzeuggruppeermöglicht es dem Benutzer, einen spezifischen Aufgabenkomplexzu bearbeiten:

1) Specification(Instrumentierung des Kernels und/oder seiner Module zur Sammlung der Tracingdaten, Erstellung der Visualisierungsschablonen, Transformationsregeln, Zuordnungender Tracingevents zu den Visualisierungsschablonen und den Transformationsregeln)
2) Gathering(Sammlung der Tracingdaten)
3) Analyzing-and-Visualizing(Darstellung der Tracingdaten, Anwendung der Transformationen auf die Visualisierungsschablonen, Darstellung der Visualisierungen, Quellcodeanzeige)

Für jede Teilaufgabemuss u.a. untersucht werden, welche Werkzeugedafür bereits existieren, über welche Eigenschaften diese verfügen und welche Werkzeuge neu erstellt werden müssen.

Einige Einsatzmöglichkeitendes Systems sollen anhand von Beispielen demonstriert werden. Dabei soll auch gezeigt werden, wie der Benutzer die Werkzeuge des Systems nutzbringend einsetzen kann.

1.3. Gliederung der Arbeit

Das Grundlagenkapitel (Kapitel 2) stellt die in dieser Arbeit verwendeten Werkzeuge vor und beschreibt deren Eigenschaften sowie die Erweiterungen, die an diesen Werkzeugen vorgenommen werden müssen. Ein Teil dieser Werkzeuge wurde im Rahmen des Fortgeschrittenen-Praktikums „Gerätetreiber-bezogenes Probing, Tracing und Viewing des Linuxkernels“ [1] entwickelt und muss für die Verwendung im Rahmen dieser Arbeit angepasst und erweitert werden.

In Kapitel 3 wird diskutiert, welche Tools für die einzelnen Arbeitsschritte zur Verfügung stehen und welche Möglichkeiten zur Beschreibung der Visualisierungsschablonen sowie der Transformationsregeln existieren.

Unter Verwendung der Tools, die laut der Diskussion aus Kapitel 3 am besten geeignet sind, werden in Kapitel 4 ein prototypischer Entwurf des Toolkits und dessen Implementierungbeschrieben.

Die Kapitel 5 und 7 demonstrieren die Fähigkeiten und Einsatzmöglichkeitendes Toolkits, das in Kapitel 4 entworfen und implementiert wurde, anhand von Anwendungsbeispielen.

In Situationen, in denen im Voraus genau bekannt ist, welche Tracingdaten zur späteren Analyse benötigt werden, kann es sinnvoll sein, nicht benötigte Tracingdaten bereits vor deren Transport in den Userspace auszufiltern. Dabei darf der Aufwand für die Filterung jedoch nicht die Ersparnisse durch die Filterung übersteigen. In Kapitel 6 werden zwei Methoden zur Filterung von Tracingdaten behandelt.

Eine Zusammenfassung der Ergebnisse dieser Arbeit befindet sich in Kapitel 8. Darüber hinaus betrachtet das Kapitel mögliche Erweiterungen des Systems.

2 Grundlagen

Dieses Kapitel beschreibt den Aufbau, die Funktionsweise sowie die Verwendung der Tools, die in dieser Arbeit eingesetzt werden. Ferner werden notwendige Veränderungen und Erweiterungen der Tools erläutert. In Kapitel 3 wird dargelegt, aus welchen Gründen gerade die in diesem Kapitel genannten Tools eingesetzt werden.

Das Kapitel ist entsprechend der in Abschnitt 1.2 angegebenen Einteilung aufgebaut. D.h. die Tools werden entsprechend ihrer Verwendung in Abschnitt 2.1. Specification, Abschnitt 2.2 Gathering oder Abschnitt 2.3 Analyzing-and-Visualizing beschrieben. Diese Einteilung ist jedoch nicht in jedem Fall eindeutig. So lassen sich Systemtap Skripte der Specification zuordnen. Das Systemtap System selbst ist jedoch für die Sammlung der Tracingdaten verantwortlich, kann also dem Gathering zugeschrieben werden.

2.1. Specification

2.1.1. XML

Die vom World Wide Web Consortium (W3C) [61] entworfene XML(Extensible Markup Language) [58, 59, 60, 65] Sprache dient der strukturierten, herstellerunabhängigen Darstellung, Speicherung sowie dem Austausch von Daten in Form von Textdateien. XML ist, wie auch HTML, ein Abkömmling von SGML(Standard Generalized Markup Language) [62, 63]. SGML ist eine Metasprache, die der Definition von Markupsprachendient. XML ist als Teilmenge von SGML selbst eine Metasprache und erlaubt die Definition von anwendungsspezifischen Markupsprachen. Dazu dienen Schemasprachenwie DTDoder XML-Schema. Durch diese können Regeln formuliert werden, die beschreiben, welche Tags, Attribute usw. in einer XML Sprache verwendet und wie diese verschachtelt werden dürfen. Beispiele für anwendungsspezifische XML Sprachen sind SVG, XHTML und RSS.

Aufbau und Syntax von XML Dokumenten:

- XML Dokumente sind hierarchisch strukturiert und beschreiben eine Baumstruktur.
- Es gibt folgende Baumknoten: Elemente, Attribute, Verarbeitungsanweisungen, Kommentare, Text
- Elemente werden durch ein Paar aus Start-Tag (<tag>) und End-Tag (</tag>) bzw. durch ein Empty-Element-Tag (<tag/>) gekennzeichnet. Beispiel: <buch>Inhalt</buch>
- Attribute können Start-Tags bzw. Empty-Element-Tags zugeordnet werden. Sie werden durch ein Schlüsselwort-Werte-Paar (attribut=“wert“) beschrieben. Tags können um beliebig viele Attribute ergänzt werden. Beispiel: <buch autor=“x“ name=“y“ ISBN=“z“>Inhalt</buch>
- Verarbeitungsanweisungendienen der Realisierung von anwendungsspezifischen Funktionen. Sie werden von XML Parsern nicht geparst und werden unverändert an die jeweilige Anwendung übergeben. Sie haben folgende Syntax: <?name ... ?>
- Kommentare haben folgende Syntax: <!-- Ich bin ein Kommentar -->
- Syntaktisch korrekte XML Dokumente müssen genau ein Wurzelelemententhalten.
- Vor dem Wurzelelement kann eine optionale XML Deklaration stehen. Diese gibt an, welche XML Version in dem Dokument zum Einsatz kommt. Ferner können das verwendete Zeichenverschlüsselungsschemasowie externe Abhängigkeiten angegeben werden. Beispiel: <?xml version="1.0" encoding="UTF-8"?>

Abbildung in dieser Leseprobe nicht enthalten

Listing 2-1: XML Beispieldatei.

Ein Beispiel eines vollständigen XML Dokuments wird in Listing 2-1 aufgezeigt. Abbildung 2-1 beinhaltet die Baumdarstellungdieses XML Dokuments.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-1: Baumdarstellung der XML Datei aus Listing 2-1. (Erstellt durch das Programm XML Viewer 3.0 [64])

2.1.2. SVG

SVG(Scalable Vector Graphics) [66, 67, 68, 69] ist eine XML-Sprache, die der Beschreibung zweidimensionaler Vektorgrafikendient. SVG ist ein offener Standard und wurde 2001 vom World Wide Web Consortium als Empfehlung veröffentlicht. Aktuelle Webbrowserkönnen einen Großteil des SVG Sprachumfangs nativ darstellen bzw. können durch Plugins(z.B. Adobe SVG Viewer [70]) um diese Funktionalität erweitert werden. Da SVG eine XML-Sprache ist, können alle XML Tools, wie z.B. XSLT auf SVG Dateien angewendet werden.

In den Abschnitten 2.1.2.2 bis 2.1.2.5 wird eine Übersicht über die wichtigsten SVG Elemente gegeben. Die Übersicht erhebt keinen Anspruch auf Vollständigkeit.

2.1.2.1. Aufbau von SVG Dateien

Wie alle XML Dokumente, beschreiben auch SVG Dateien eine Baumstruktur. Wurzelelementmuss dabei stets das <svg> Element sein. Durch dessen Attribute „width“ und „height“ wird die Bildgrößefestgelegt. Dem Wurzelelement muss die XML-Deklaration vorausgehen. Siehe Listing 2-2.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2-2: Aufbau von SVG Dateien.

2.1.2.2. Grafische Primitive

Tabelle 2-1 zeigt die durch den SVGStandard definierten grafischen Primitiveanhand von Beispielen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-1: Grafische Primitive von SVG.

2.1.2.3. Text

Zum Einbetten von Text in SVG Grafiken dient das <text> Element. Text kann positioniert, gedreht und formatiert werden. Außerdem kann Text mithilfe des <textPath> Elements an einem Pfad ausgerichtet werden. Beispiel für ein Textelement: <text x="50" y="50" font-size="50px" font-style="italic" font-weight="bold"> Ich bin ein Text</text>

2.1.2.4. Elemente zur Strukturierung

SVG Elemente können durch das <g> Element gruppiert werden. Gruppen können geschachtelt werden.

Jedem SVG Element und jeder Gruppe von Elementen kann ein ID Attributzugeordnet werden. SVG Elemente und Gruppen von Elementen, die über ein ID Attribut verfügen, können durch das <use> Element wiederverwendet werden. D.h. durch das <use> Element können beliebig viele Instanzen des referenzierten Elements bzw. der referenzierten Gruppe angelegt werden.

Zwischen den Tags <defs> und </defs> können Elemente und Gruppen von Elementen definiert werden. Diese sind jedoch inaktiv und werden nur dann dargestellt, wenn sie durch ein <use> Element instanziiert werden.

2.1.2.5. Sonstige Elemente und Funktionen von SVG

Neben den bereits genannten Elementen existieren u.a. noch Elemente zur Beschreibung von Filtern, Mustern, Farbverläufen und Animationen. SVG kennt Bewegungs-, Farb- und Attributanimationen. Ferner bietet SVG noch die Möglichkeit, Rastergrafiken durch das <image> Element einzubinden. Außerdem muss noch erwähnt werden, dass SVG auch über Möglichkeiten zur Interaktion verfügt. Dazu bietet SVG ein Eventmodell und erlaubt den Einsatz von internen (ECMAScript) und externen Skripten.

2.1.2.6. Beispiele

Listing 2-3 enthält den Quellcode einer einfachen SVG Grafik. Die entsprechende grafische Darstellung zeigt Abbildung 2-2. Die SVG Datei besteht aus zwei grafischen Primitiven und einem Textelement. Durch die „fill“ Attribute werden die Füllfarben der grafischen Primitive bzw. die Farbe des Textes festgelegt. Das „stroke“ Attribut gibt an, welche Linienfarbe für das betreffende Element verwendet werden soll.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2-3: Einfaches Beispiel einer SVG Datei.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-2: Grafische Darstellung des SVG Codes aus Listing 2-3.

Eine komplexere SVG Datei ist in Listing 2-4 enthalten. In dieser Datei werden alle SVG Elemente aus den Abschnitten 2.1.2.2 bis 2.1.2.4 verwendet. Insbesondere werden in dieser SVG Datei die Strukturierungselementevon SVG eingesetzt. So wird innerhalb der Tags <defs> und </defs> eine Gruppe definiert und mit einem ID Attribut versehen. Durch die drei <use> Elemente werden drei Instanzen dieser Gruppe angelegt. Diese Instanzen unterscheiden sich durch ihre Positionen, welche durch die „translate“ Attribute der <use> Elemente verändert werden. Innerhalb der Tags <defs> und </defs> wird ferner ein Pfad definiert. Dieser wird durch das <textPath> Element verwendet, um dessen Text entlang des Pfades auszurichten. Die grafische Darstellung der SVG Datei ist in Abbildung 2-3 zu sehen.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2-4: Komplexeres SVG Beispiel, in dem Strukturierungselemente verwendet werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-3: Grafische Darstellung der SVG Datei aus Listing 2-4.

2.1.3. XSL Transformations (XSLT)

XSL Transformations(XSLT) [59, 74, 75, 76] ist Teil der Extensible Stylesheet Language (XSL) [71, 72, 73]. XSL ist eine Familie von Sprachen zur Erzeugung von Layouts für XML-Dokumente. Die deklarative Sprache XSLT dient der Beschreibung von Transformationen von XML Dokumenten und baut auf deren logischer Baumstrukturauf. Das Ergebnis einer solchen Transformationkann wieder eine XML Datei oder auch eine Datei in einem beliebigen Ausgabeformatsein. XSLT wird u.a. zur Transformation von XML nach HTML verwendet. Die XSLT-Programme, sogenannte XSLT Stylesheets, sind ebenfalls XML Dateien. XSLT ist Turing-Vollständig[48, 77, 78, 79]. XSLT-Prozessoren, wie z.B. Saxon-B 8.8[20], lesen XSLT Stylesheets und die zu transformierenden XML Dateien ein und führen die in den Stylesheets beschriebenen Transformationen aus.

In den folgenden Abschnitten wird die XSLT Sprache beschrieben und deren Einsatz wird anhand eines Beispiels demonstriert. Dabei wird XSLT in der Version 2.0 beschrieben bzw. verwendet.

2.1.3.1. Aufbau und Funktionsweise von XSLT Stylesheets

Da XSLT StylesheetsXML Dateien sind, beginnen sie mit der XML-Deklaration. Wurzelelementist immer das <xsl:stylesheet> Element. Die verwendete XSLT Version muss als Parameter „version“ des Wurzelelements angegeben werden. Der Namensraumfür XSLT (=xsl) muss eingebunden werden. Siehe Listing 2-5.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2-5: Aufbau von XSLT Stylesheets.

XSLT Stylesheets bestehen neben der XML-Deklaration und dem Wurzelelement im Wesentlichen aus einer Menge von Transformationsregeln, sogenannten Templates.

Templates :

Templates werden durch das <xsl:template> Element definiert. Dieses verfügt über ein „match“ und ein „name“ Attribut. Mindestens eines dieser Attribute muss angegeben werden. Wert des „match“ Attributs muss ein Pattern sein, das die Menge an Elementen beschreibt, für die das Template ausgeführt werden soll. Innerhalb des <xsl:template> Elements wird definiert, welche Ausgabe produziert werden soll, wenn das Template ausgeführt wird.

Bei der Transformationeiner XML Datei durch einen XSLT-Prozessorüberprüft dieser für jedes Element der Eingabedatei, welche Pattern auf das jeweilige Element passen. Aus diesen Pattern wird das spezifischste ausgewählt und das entsprechenden Template wird ausgeführt.

Die Pattern müssen in der Sprache XPath(XML Path Language) [59, 80, 81, 82, 83] formuliert werden. XPath ist eine Sprache, die dem Auffinden von Knoten und Informationen innerhalb von XML Dokumenten dient. Ein XPath Ausdruck liefert eine Knotenmenge, einen String, einen booleschen Wert oder eine Zahl. Die gefundenen Informationen können außerdem durch XPath Operatorenund durch benutzerdefinierte Funktionen (ab XPath 2.0) verändert werden. Die Adressierungvon Knoten und Informationen in XPath ähnelt der Adressierung in Dateisystemen und baut auf der Baumstrukturvon XML auf. Sie erfolgt durch einen oder mehrere, durch das Zeichen „/“ getrennte Lokalisierungsschritte. Ein Lokalisierungsschritt besteht aus einer Achse bezüglich der Baumstruktur des XML Dokuments, einem Knotentestzur Identifizierung von Knoten innerhalb der Achse und optional aus einem oder mehreren Prädikaten zur weiteren Einschränkung der Auswahl. Tabelle 2-2 zeigt einige Beispiele für XPath Ausdrücke.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-2: Beispiele für XPath Ausdrücke. Die Beispiele beziehen sich auf die XML Datei aus Listing 2-1. Siehe auch Abbildung 2-1.

Benannte Templates, d.h. Templates, die über ein „name“ Attribut verfügen, können durch andere Templates unter Angabe dieses Namens aufgerufen werden. Dabei ist auch die Übergabe von Parametern möglich. Solche Templates können also in gewisser Weise als Funktionen angesehen werden.

XSLT Elemente:

Zur Verwendung innerhalb von Templates steht eine Vielzahl von XSLT Elementen zur Verfügung. Die Elemente, die für die vorliegenden Arbeit am wichtigsten sind, werden in Tabelle 2-3 vorgestellt und beschrieben.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-3: Für die vorliegende Arbeit wichtige XSLT Elemente.

2.1.3.2. Beispiel

Listing 2-6 enthält ein XSLT Stylesheet, welches die XML Repräsentation der Informationen aus Listing 2-1 in eine HTML Repräsentation umwandelt, d.h. die XML Datei wird in eine HTML Datei transformiert. Das Ergebnis der Transformation ist in Abbildung 2-4 dargestellt. Das XSLT Stylesheet besteht aus 5 Templates, von denen zwei benannte Templates sind. Das Pattern „/“ des Templates  beschreibt das ganze Dokument. Aus diesem Grund beginnt die Verarbeitung des XSLT Stylesheets durch den XSLT-Prozessor mit der Ausführung dieses Templates. Dieses Template produziert den HTML Header und veranlasst durch <xsl:apply-templates/> die Abarbeitung aller Kindknoten des aktuellen Knotens. Das Pattern des Templates ‚ beschreibt einen solchen Kindknoten, was die Ausführung dieses Templates zur Folge hat. Dieses Template gibt durch <xsl:value-of select="."/> den Inhalt des aktuellen Knotens (.) aus. Ferner wird der Inhalt eines weiteren Knotens (../modell) ausgegeben. Um diese Ausgaben als HTML Überschrift zu präsentieren, werden die entsprechenden HTML Tags <h1> und </h1> produziert. Nachdem Template ‚ abgearbeitet wurde, werden in Template  die benannten Templates ƒ und „ durch das XSLT Element <xsl:call-template> aufgerufen. Template ƒ verwendet ein <xsl:choose> Element, um in Abhängigkeit des Attributs „einheit“ eine Umrechnung durchzuführen. In Template „ werden alle Kindelemente des „Hoechstgeschwindigkeit“ Elements unter Verwendung des <xsl:for-each> Elements in Form einer HTML Tabelle ausgegeben. Template…produziert keine Ausgabe. XSLT verfügt über ein Default Template für Textknoten, das den entsprechenden Text ausgibt. Ohne Template…würde dieses Default Template auf alle Textknoten angewendet und würde deren Texte ausgeben.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2-6: XSLT Stylesheet, das die XML Datei aus Listing 2-1 in eine HTML Datei transformiert. Das Ergebnis dieser Transformation zeigt Abbildung 2-4. Die HTML Tags, die durch das XSLT Stylesheet produziert werden, sind rot markiert. Die XSLT Tags sind grün markiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-4: Darstellung der HTML Datei, die durch Anwendung des XSLT Stylesheets aus Listing 2-6 auf die XML Datei aus Listing 2-1 erzeugt wird.

2.1.4. XML Metadata Interchange Format (XMI)

Die XML Sprache XMI(XML Metadata Interchange Format) [30, 31, 32] ist ein offener Standard der Object Management Group [30], der dem Datenaustausch von Objekten auf Basis von Meta-Metamodellennach der Meta-Object Facility (MOF) [33, 34] dient. XMI ermöglicht also die Speicherung und den Austausch aller Metadaten, die durch die MOF ausgedrückt werden können. Dies umfasst u.a. auch UMLModelle. D.h. XMI ermöglicht die Speicherung von UML Modellen in einem offenen, herstellerunabhängigen Format und ermöglicht somit den Austausch von UML-Modellenzwischen UML-Toolsverschiedener Hersteller.

Beispiel:

Im Folgenden wird die Verwendung von XMI 1.0 zur Speicherung von UML Diagrammen anhand des einfachen UML Klassendiagrammsaus Abbildung 2-5 demonstriert. Dieses Klassendiagramm besteht nur aus einer Klasse, die über zwei Attribute verfügt. Da das XMI Format UML Diagramme in Form von MOF-basierten Metamodellenbeschreibt, muss zunächst die Metamodelldarstellungdes Klassendiagramms betrachtet werden. Diese wird in Abbildung 2-6 gezeigt. Nicht verwendete Meta-Klassen sind dabei nicht dargestellt. Die XMI Darstellung des Klassendiagramms aus Abbildung 2-5 ist nichts weiter als die Beschreibung des Metamodellsaus Abbildung 2-6 und wird in Listing 2-7 gezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-5: Beispiel eines einfachen Klassendiagramms zur Demonstration des XMI Formats.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-6: Metamodelldarstellung des einfachen Klassendiagramms aus Abbildung 2-5.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2-7: XMI Darstellung des einfachen UML Klassendiagramms aus Abbildung 2-5

.

2.2. Gathering

2.2.1. KProbes, JProbes und Kretprobes

KProbes, JProbesund Kretprobes[1, 54, 55, 56, 57] werden durch das in Abschnitt 2.2.2 beschriebene Systemtap System verwendet und sollen deshalb an dieser Stelle kurz angesprochen werden. Mit KProbes, JProbes und Kretprobes lassen sich Halte- und Messpunkte in das laufende Betriebssystemeinfügen. Aus Kernelsicht stellen sie automatisierte Breakpointsdar. Jeder KProbe ist ein Objekt bestehend aus Breakpoint-Adresse, Pre-Handler, Post-Handler, Fault-Handlerund Break-Handlerzugeordnet. Mit der Instanziierung des Objekts durch die Funktion „register_kprobe()“ wird der Maschinenbefehlan der Probe-Point-Adresse gegen den eines Debugger-Breakpointsausgetauscht. Wenn der Prozessor auf den Breakpoint trifft, werden die Handlerfunktionenausgeführt. Diese können dann Tracingdaten ermitteln und speichern. JProbes ermöglichen den Zugriff auf die Übergabeparametereiner Funktion. Sie verwenden nur einen Handler, dessen Übergabeparameter denen der zu untersuchenden Funktion entsprechen müssen. Kretprobes ermöglichen den Zugriff auf den Rückgabewerteiner Funktion.

2.2.2. Systemtap

Das SystemtapSystem [2] ermöglicht die dynamische Instrumentierungdes Linuxkerns und seiner Module. Es baut auf der KProbes/JProbes/KretprobesInfrastruktur auf und benötigt deshalb keinen Kernelpatch. Das Systemtap System bietet eine C-ähnliche Skriptsprachean, um sogenannte Kernel Probeszu definieren.

Kernel Probes bestehen aus einer Handlerroutine, die Tracingdaten sammeln kann und einer Ausführungsbedigungfür die Handlerroutine. Die Ausführungsbedigung kann das Ablaufen eines Timers, der Start bzw. das Ende der Skriptausführungoder das Erreichen einer bestimmten Position innerhalb des Kernels bzw. eines Kernelmoduls sein. Solche Positionen können der Anfang bzw. das Ende von Funktionen sowie der Anfang von Inlinefunktionen des Kernels und seiner Module sein. Die Adressen der Funktionsaufrufe bzw. der Rückkehr aus den Funktionen müssen dabei, im Gegensatz zu KProbes, JProbes und Kretprobes nicht vom Benutzer ermittelt und angegeben werden, sondern werden durch Systemtap anhand des Funktionsnamensund des Modulnamensautomatisch gefunden. Es besteht jedoch trotzdem die Möglichkeit, an jeder beliebigen Stelle eine Probe durch Angabe einer bekannten modul- bzw. kernelrelativen Adresse einzufügen.

2.2.2.1. Funktionsweise von Systemtap

Die Systemtap Skriptewerden in Kernelmodule umgesetzt, welche dann geladen werden und die Tracingdaten mittels KProbes, JProbesund Kretprobessammeln. Bei der Erstellung der Kernelmodule werden DebuginfoELF-Objekteverwendet, um zu den Funktionsnamen die zu instrumentierenden Adressen automatisch zu finden.

Abbildung 2-7 zeigt eine schematische Darstellung der Funktionsweise von Systemtap. Nachdem das Systemtap Skript (probe.stp) geparst wurde, werden die Adressen der zu instrumentierenden Kernel- bzw. Kernelmodulfunktionen aus den entsprechenden Debuginfo ELF-Objektenermittelt und die Referenzen auf die Skriptbibliothekwerden aufgelöst. Im nächsten Schritt werden diese Informationen zur Übersetzung des Systemtap Skripts in C-Quellcode (probe.c) verwendet. Unter Verwendung der Systemtap Laufzeitbibliothekwird dieser Quellcode in ein Kernelmodul (probe.ko) übersetzt. Dieses wird durch den Systemtapdaemon(stpd) in den Kernel geladen und sammelt dann die Tracingdaten unter Verwendung von KProbes, JProbes und Kretprobes. Die gesammelten Tracingdaten werden vom Systemtapdaemon übernommen und ausgegeben oder gespeichert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-7: Schematische Darstellung der Funktionsweise des Systemtap Systems.

2.2.2.2. Welche Tracingdaten können durch Systemtap Probes gesammelt werden ?

Systemtap Probes, die im Gegensatz zu asynchronen Probes wie z.B. Timer Probes, eine bestimmte Adresse des Kernels oder eines Kernelmoduls instrumentieren, können auf den Kontext des Probe Points zugreifen und die Werte von dort verfügbaren Variablen auslesen. Auch die Auflösung von Pointerkettenist in beschränktem Maße möglich.

Bei der Instrumentierung von Funktionen kann außerdem, wie in Tabelle 2-4 gezeigt wird, auf Funktionsparameterund Rückgabewertezugegriffen werden.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-4: Zugriff auf Informationen bei der Instrumentierung von Kernel- bzw. Kernelmodulfunktionen durch Systemtap.

Ferner kann auf Kontextinformationen wie z.B. CPU ID, PID, PPID zugegriffen werden. Zum Zugriff auf diese Daten existieren vordefinierte Systemtap Funktionen.

2.2.2.3. Systemtap Skriptsprache

An dieser Stelle wird nur ein kurzer Überblick über die Systemtap Skriptsprachegegeben. Eine detailliertere Beschreibung befindet sich in [53].

Die Skriptsprache verwendet eine einfache, C-ähnliche Syntaxund verfügt nur über ein Minimum an Typen (64 Bit Ganzzahlen, Strings, Assoziative Arrays, Statistikobjekte). Sie beschreibt die Verbindung von HandlerSubroutinen mit Probe Points. Es gibt folgende Probe Points:

- Beliebige Position innerhalb des Kernels bzw. eines Kernelmoduls.
- Aufruf oder Rückkehr aus einer Kernel- bzw. Kernelmodulfunktion.
- Aufruf einer Inlinefunktion des Kernels bzw. eines Kernelmoduls.
- Spezielles Event wie z.B. Timer, Counter, Start bzw. Ende der Skriptausführung.

Trifft der Prozessor auf einen Probe Point oder tritt ein spezielles Event wie z.B. Ablauf eines Timers auf, wird die entsprechende Handlerroutineausgeführt und kann Tracingdaten sammeln.

Die Skriptsprache verfügt über 3 toplevel Konstrukte:

1) Probe Definitionen (Probe Point(s) + Handlerfunktion)
2) Definitionen von Hilfsfunktionen. Diese können in der Skriptsprache selbst definierte Funktionen oder eingebettete C-Funktionen sein.
3) Globale Variablendeklarationen.

2.2.2.3.1. Definition von Systemtap Probes

Systemtap Probes setzen sich aus einer Liste von Probe Points und der dazugehörigen Handlerroutinezusammen. Zur Beschreibung der Probe Points stehen die folgenden Sprachkonstrukte zur Verfügung:

- probe begin:

Probe Point, dessen Handler zu Beginn der Systemtap-Ausführung

gestartet wird.

- probe end:

Probe Point, dessen Handler am Ende der Systemtap-Ausführung

gestartet wird.

- probe kernel.function("sys_read"):

Der Handler wird bei jedem Aufruf von „sys_read“ ausgeführt.

- probe kernel.inline("skb_bond"):

Der Handler wird bei jedem Aufruf einer Inlinekopieder Funktion

„skb_bond“ ausgeführt.

- probe syscall.open.return:

Der Handler wird bei jeder Rückkehr aus der „sys_open“ Funktion

ausgeführt.

- probe module("ppdriver").function("llseek"):

Der Handler wird bei jedem Aufruf der Funktion „llseek“ des

Kernelmoduls ppdriver ausgeführt.

- probe module("ppdriver").inline("myInlineFunc"):

Der Handler wird bei jedem Aufruf einer Inlinekopie der Funktion

„myInlineFunc“ des Kernelmoduls ppdriver ausgeführt.

- probe module("parport").statement(0x6a5):

Handlerausführung bei jedem Erreichen der Instruktion bei Adresse 0x6a5 im parport Modul.

- probe timer.ms(50):

Alle 50 Millisekunden wird der Handler ausgeführt.

- probe timer.jiffies(20):

Handlerausführung alle 20 Jiffies.

Außerdem ist es möglich, Wildcards(*) in den Funktionsnamen zu verwenden und den Namen der Quellcodedatei, in der sich die zu untersuchende Funktion befindet, mittels @Dateiname anzugeben.

An die Liste der Probe Points muss sich der Code der Handlerroutine anschließen. Innerhalb der Handlerroutine kann durch den Systemtap Operator $ auf Kontextvariable und auf Übergabe- und Rückgabeparameterder instrumentierten Funktionen zugegriffen werden. Innerhalb der Handlerroutine können Hilfsfunktionen aufrufen werden. Ein einfaches Beispiel für eine Systemtap Probe ist in Listing 2-8 enthalten. Probe Point in dem Beispiel ist die Rückkehr aus der Kernelfunktion „sys_read“. Der Probe Handler gibt den Rückgabewert sowie zwei Übergabeparameter der Funktion aus.

probe kernel.function("sys_read").return

{

printf("sys_read return: retval: %d fd param: %d count param: %d\n", $return, $fd, $count);

}

Listing 2-8: Systemtap Probe, die die Rückkehr aus der Kernelfunktion „sys_read“ instrumentiert und den Rückgabewert sowie zwei Übergabeparameter der Funktion ausgibt.

Systemtap Probes können auch als sogenannte Probe Aliasesdefiniert werden. Ein Probe Alias ist eine benannte, inaktive Probe. Ein Probe Alias kann verwendet werden, um neue Probes zu definieren. Es gibt zwei Arten von Probe Aliases. Dies sind Prolog Probe Aliases und Epilog Probe Aliases. Bei der Abarbeitung einer Probe, die mithilfe eines Prolog Probe Alias definiert wurde, wird vor Ausführung des Handlercodes der Probe, der Handlercode des Prolog Probe Alias ausgeführt. Bei Probes, die unter Verwendung eines Epilog Probe Alias definiert wurden, wird zuerst der Handlercode der Probe und anschließend der Code des Epilog Probe Alias ausgeführt. Die Definition und die Verwendung eines Prolog Probe Alias wird in Listing 2-9 demonstriert. Bei der Definition von Epilog Probe Alias wird „+=“ anstatt „=“ in der Aliasdefinition verwendet.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2-9: Verwendung eines Probe Alias.

2.2.2.3.2. Definition von Hilfsfunktionen

Systemtap erlaubt die Definition und Verwendung von zwei Arten von Hilfsfunktionen. Dies sind zum einen Hilfsfunktionen, die in der Systemtap Skriptsprache geschrieben sind. Zum anderen sind dies eingebettete C- Funktionen.

Die Syntax für die Definition von Hilfsfunktionen in der Systemtap Skriptsprache ähnelt stark der Syntax von Funktionsdefinitionen in awk. Listing 2-10 zeigt ein Beispiel einer Funktionsdefinition in der Systemtap Skriptsprache.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2-10: Funktionsdefinition in der Systemtap Skriptsprache.

Eingebettete C-Funktionen erlauben es, im Gegensatz zu normalen Systemtap Funktionen, Kernelroutinen aufzurufen. Überdies ist es dadurch möglich, auf Datenstrukturen des Kernelszuzugreifen. Die Formulierung der Funktion aus Listing 2-10 als eingebettete C-Funktion ist in Listing 2-11 dargestellt. Bei der Verwendung von eingebetteten C-Funktionen ist jedoch Folgendes zu beachten:

- Unbekannte oder ungültige Pointer dürfen nicht dereferenziert werden.
- Es dürfen keine Kernelroutinen verwendet werden, die ein Schlafenlegen verursachen können.
- Es können unerwünschte Rekursionen auftreten, falls innerhalb einer eingebetteten C-Funktion eine, durch eine Probe instrumentierte, Kernelfunktion aufgerufen wird und falls deren Probehandler wiederum diese eingebettete C-Funktion aufruft.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2-11: Formulierung der Funktion aus Listing 2-10 als eingebettete C-Funktion.

2.2.2.3.3. Ausgabe durch Systemtap

Zur Ausgabe von Fehlermeldungen existiert die Systemtap Funktion „error()“. Der Ausgabe dienen die Systemtap Funktionen „print()“, „log()“ und „printf()“. Die Funktionen „print()“, „log()“ dienen der Ausgabe von Strings. Durch „printf()“ ist die formatierte Ausgabe wie bei der gleichnamigen C-Funktion möglich. Es sind jedoch nur folgende Formatangabenmöglich:

- %s String

- %d 64 Bit Ganzzahl

- %1b, %2b, %4b, %8b, %b Binäre Ausgabe. Die Feldbreite gibt die Anzahl der zu schreibenden Bytes an. Der Defaultwert beträgt 4 Bytes.

- %1n, %2n, %4n, %n Ausgabe der Länge des durch „printf()“ produzierten Strings. Die Feldbreite gibt die Anzahl der zu schreibenden Bytes an. Der Defaultwert beträgt 2 Bytes.

2.2.2.3.4. Beispielskript

Listing 2-12 zeigt ein Beispiel eines kompletten Systemtap Skripts. Die globale Variable „numberOfSchedulingChanges“ speichert die Anzahl der Prozesswechsel, die während der Skriptausführung erfolgt sind. Die eingebettete C-Funktion „getFrequency()“ liefert die CPU-Frequenz in KHz. Die Funktion „judgePC()“ gibt eine Bewertung der CPU-Frequenz aus. Die Probe „begin“ wird am Anfang der Skriptausführung gestartet und gibt die Mitteilung “Tracing gestartet.” aus. Durch „probe schedulingChange = ...“ wird ein Probe Alias definiert, der die Prozesswechsel zählt. Dieser Probe Alias wird verwendet, um durch „probe schedulingChange {}“ eine aktive Probe zu definieren. Die Timer Probe „probe timer.ms(1000)“ wird 1000 Millisekunden nach dem Start des Skripts ausgeführt und veranlasst das Ende der Skriptausführung durch den Aufruf von „exit()“. Am Ende der Skriptausführung wird die Probe „end“ ausgeführt. Sie gibt die Taktfrequenz des Prozessors in MHz aus, ruft die Hilfsfunktion judgePC() auf und gibt die Anzahl der während der Ausführung des Skriptes aufgetretenen Prozesswechsel aus.

Abbildung in dieser Leseprobe nicht enthalten

2.3. Analyzing-and-Visualizing

2.3.1. LTT

Das Linux Trace Toolkit (LTT) [52] wurde von Karim Yaghmour zur Aufzeichnung, Analyse und Visualisierung von Tracingdaten bezüglich des Linuxkerns entwickelt. Dabei werden durch einen KernelpatchAufrufe von Tracingfunktionenan relevanten Stellen in den Kernel eingebracht. Wird der gepatchte Kernelcode ausgeführt, werden Tracingdaten wie z.B. Funktionsparameter oder Werte von globalen bzw. lokalen Variablen in den Userspace weitergeleitet und gespeichert. Unter Verwendung des LTTVisualizerskönnen die gesammelten Tracingdaten nachgelagert analysiert und visualisiert werden.

Abbildung 2-8 gibt einen Überblick über den Aufbau des LTT Toolkits und veranschaulicht dessen Informationsfluss. Durch die gepatchten Kernelanteile werden die Tracingevents erzeugt und durch die Kernel Trace Facilitiesan das Kernelmodul „Trace Module“ weitergeleitet. Dort werden die Tracingdaten unter Verwendung des Relay Dateisystems gepuffert. Ist der Puffer gefüllt, werden die gepufferten Tracingdaten vom Trace Daemonübernommen und als Tracedateien im Userspace gespeichert. Diese Dateien dienen als Eingabe für den LTT Visualizer.

Da das LTT Projekt eingestellt wurde, werden keine neuen Kernelpatches entwickelt. Die letzte Version von LTT enthält einen Patch für den Linux Kernel

2.6.9.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-8: Aufbau und Informationsfluss sowie Quelldateien von LTT.

2.3.2. LTTng und LTTV

Das LTTng+ LTTVProjekt [3] ist eine Weiterentwicklung des eingestellten LTT Projektes. Linux Trace Toolkit Next Generation (LTTng) und der Linux Trace Toolkit Viewer (LTTV) sind eine Entwicklung von Mathieu Desnoyers. LTTng baut auf den LTT-Mechanismen zur Ermittlung, Weiterleitung und Speicherung der Tracingdaten auf. LTTng entspricht also dem Kernelpatch, den Kernel Trace Facilities, dem Trace Modulesowie dem Trace Daemon von LTT. LTTV dient der Analyse und Visualisierung der Tracingdaten, entspricht also dem LTT Visualizer.

Da die Tracingdaten im Rahmen dieser Arbeit nicht durch LTTng, sondern durch Systemtap gesammelt werden sollen, wird an dieser Stelle nicht weiter auf LTTng eingegangen. Eine ausführlichere Betrachtung von LTTng befindet sich in [1]. LTTV wird in dieser Arbeit zur Analyse und Visualisierung von Tracingdaten verwendet und um zusätzliche Funktionalität erweitert. Aus diesem Grund wird im Folgenden näher darauf eingegangen. Da Tracingdaten durch Systemtap anstatt durch LTTng gesammelt und durch LTTV visualisiert werden sollen, muss dabei insbesondere das vom LTTV Viewer erwartete Eingabeformatgeschildert werden.

2.3.2.1. LTTV Viewer

Der LTTV Viewerwurde im Gegensatz zum LTT Visualizer so konzipiert, dass er modular aufgebaut und leicht erweiterbar ist. Der LTTV Viewer kann durch neue Module erweitert werden. Diese können dynamisch geladen und entfernt werden. Darüber hinaus sind die Eventtypenbeim LTTV Viewer nicht fest vorgegeben und werden stattdessen durch eine XML Sprache definiert. Folglich kann der LTTV Viewer beliebige Typen von Tracingevents verarbeiten, sofern Eventdefinitionendafür existieren.

Ein Screenshot des LTTV Viewers mit 3 geladenen Modulen wird in Abbildung 2-9 gezeigt. Das Statistics Viewer Modul berechnet Statistikinformationen(z.B. Anzahl der Auftreten der Events) aus den Tracingdaten. Das Event Viewer Modul zeigt eine Liste der Tracingevents und ihrer Eventdetails. Die zeitliche Abfolge der Events wird vom Control Flow Viewer Modul durch die Anordnung der Events auf einer farbcodierten Zeitachsevisualisiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-9: Screenshot des LTTV Viewers mit 3 geladenen Modulen.

Dateiformat des LTTV Viewers:

An dieser Stelle soll das Dateiformat, das der LTTV Viewer (Version 0.8.8) als Eingabe erwartet, grob beschrieben werden. Die technischen Einzelheiten des Formats werden in [1] ausführlich erklärt und sollen deshalb an dieser Stelle nicht betrachtet werden.

LTTV erwartet als Eingabe einen Verzeichnisbaum. Abbildung 2-10 zeigt ein Beispiel eines solchen Verzeichnisbaums für ein System mit zwei Prozessoren. Dabei müssen sich im Unterverzeichnis „eventdefs“ die Definitionen der Eventtypenbefinden. Diese Definitionen beschreiben den Aufbau der Tracingevents, enthalten also keine Tracingdaten. Die Tracingevents müssen in sogenannte Facilities(= Gruppen von Events) eingeteilt werden. Jedes Facility muss in einer separaten XML Datei definiert werden. Ein Beispiel für eine solche Definition ist in Listing 2-13 zu finden. Das Facility aus dem Beispiel besteht aus 3 verschiedenen Typen von Tracingevents. Definitionen von Eventtypen bestehen jeweils aus einer optionalen Beschreibung und den Definitionen der Felder, aus denen Events dieses Typs zusammengesetzt sind.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-10: LTTV erwartet als Eingabe einen Verzeichnisbaum. Dargestellt ist ein Beispiel eines solchen Verzeichnisbaums für ein System mit 2 Prozessoren.

Die Tracingdaten werden durch LTTV unterteilt in die eigentlichen Tracingdaten und in Steuerdaten. Die eigentlichen Tracingdaten müssen in den Dateien cpu_x gespeichert werden. Die Steuerdaten müssen sich in dem Unterverzeichnis „control“ in den Dateien facilities_x befinden. Sie enthalten u.a. sogenannte HeartbeatEvents (=Zeitstempel, time_heartbeat Event). Die Steuerdaten und die eigentlichen Tracingdaten werden jeweils in einer Datei pro CPU in einem Binärformatgespeichert.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2-13: Beispiel einer Facilitydefinition für den LTTV Viewer. Das gezeigte Facility besteht aus 3 verschiedenen Typen von Tracingevents.

2.3.3. Verbindung von Systemtap und LTTV Viewer

In diesem Abschnitt wird geklärt, ob und wie es möglich ist, durch Systemtap gesammelte Tracingdaten durch den LTTV Viewer darzustellen. Dabei werden Ergebnisse aus [1] („Fortgeschrittenen-Praktikum Gerätetreiber-bezogenes Probing, Tracing und Viewing des Linuxkernels“) verwendet.

In [1] wurde gezeigt, dass alle von LTTV benötigten Informationen durch Systemtap geliefert werden können. Es wurde jedoch auch gezeigt, dass es nicht möglich ist, durch Systemtap gesammelte Tracingdaten direkt durch Systemtap im Format des LTTV Viewers auszugeben. Dies liegt u.a. daran, dass Systemtap nur in eine Datei schreiben kann, LTTV aber einen Verzeichnisbaumerwartet.

Zur Lösung dieses Problems wurde in [1] ein Zwischenformatentwickelt, das es erlaubt, alle von LTTV benötigten Daten in einer durch Systemtap produzierbaren Form in einer Datei zu speichern. Zur Konvertierungdieses Zwischenformatsin das Format des LTTV Viewers wurde in [1] ein entsprechendes Konvertierungsprogramm(„convertTrace“) entwickelt. Dieses Programm erstellt unter Verwendung der Eventdefinitionenaus den Tracingdaten im Zwischenformat einen Verzeichnisbaum, der als Eingabe von LTTV dient. Siehe Abbildung 2-11.

[...]