summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorManuel Traut <manut@mecka.net>2012-07-17 10:26:07 +0200
committerManuel Traut <manut@linutronix.de>2018-03-16 21:39:30 +0100
commit4fd7806b30863b20f1126007d9437cd18a1b276f (patch)
tree03050c48c810d490b7c2d39b132f3b50be239d30
parent3313ef4579ea767f42a2c86d72fc971f2cbc4fd6 (diff)
add pruefung 2011
Signed-off-by: Manuel Traut <manut@mecka.net>
-rw-r--r--pruefung.txt204
1 files changed, 204 insertions, 0 deletions
diff --git a/pruefung.txt b/pruefung.txt
new file mode 100644
index 0000000..95efe91
--- /dev/null
+++ b/pruefung.txt
@@ -0,0 +1,204 @@
+Was versteht man unter dem Begriff 'Kernelpatch'? (1) - 1min
+
+- Unterschied zwischen zwei Quellcodeversionen in einem gut lesbaren Format (1)
+
+Für die Linuxkernelentwicklung wurde das Versionskontrollsystem git entwickelt.
+Worin liegen die Vorteile von git für die Linuxkernelentwicklung? (3) - 4min
+Nennen Sie mind. 6
+
+- pull Prinzip, ein Maintainer muss sich Code vom Entwickler holen (0.5)
+- komplette Historie lokal verfügbar (0.5)
+- branches können z.B. für Testzwecke einfach angelegt und gelöscht werden (0.5)
+- sehr gute Unterstützung für merging (0.5)
+- entwicklungsunterstützende Funktionen (git-bisect, git-format-patch, ..) (0.5)
+- verschiedene Übertragungsprotokolle (http, git, ssh) (0.5)
+- mittels git-blame kann herausgefunden werden, in welchem Kontext eine Änderung
+ eingeflossen ist (0.5)
+- ist opensource Software (0.5)
+- ...
+
+Beschreiben Sie den Releasezyklus des Linuxkernels. Erklären Sie in diesem
+Zusammenhang auch die Begriffe 'Release Candidate', 'Release', 'stable Kernel',
+'staging' und 'next'.
+(3,5 Punkte für sinnvolle Erklärung, 0.5 Punkte pro Begriff -> 6 Punkte) - 10min
+
+Nach einem Kernelrelease splitet sich der Code in den stable Zweig in dem nur
+noch sicherheitskritische und Bugfix Patche eingepflegt werden und den aktuellen
+Entwicklungszweig. Im Entwicklungszweig werden in einem ca. 2 Wochen großen
+Mergewindow alle funktionallen, großen Erweiterungen für das nächste Release
+integriert. Release Candidate 1 beendet das Merge Window und ab jetzt sollten
+nur noch Regressions, Security Issues und Bugs gefixt werden. Ca. wöchentlich
+wird ein neuer Release Candidate veröffentlicht. Nach typischerweise 6 - 8 RCs
+entsteht eine neues Release.
+
+Staging ist ein Unterordner im Kerneltree in welchem noch nicht fertig
+entwickelte Treiber eingeordnet sind. Sie werden aus staging entfernt und in den
+Kernel integriert sobald Sie stabil funktionieren. Sie werden gelöscht, falls
+keine aktive Weiterentwicklung mehr stattfindet. Es ist einfacher einen Kernel
+'in tree' zu entwickeln.
+
+Linux Next ist ein eigener git-tree in dem die Änderungen für das kommende Merge
+Window gesammelt werden können.
+stabil und komplett sind
+
+// Erklären Sie an einem Beispiel die Aufgaben eines Linux Kernel Maintainers.
+
+Sie haben zwischen rcN und rcN+1 Ihre Kernelkonfiguration nicht verändert.
+Kernel rcN funktioniert auf Ihrem Laptop, rcN+1 läuft in einen BUG, bevor der
+Initprozess angesprungen werden kann. Wie gehen Sie vor, damit auch zukünftige
+Linuxkernel auf Ihrem Laptop booten? (3 Punkte) - 4 Minuten
+
+git-bisect bis Fehler identifiziert, Bug fixen und Patch an LKML oder
+detailierter Bugreport mit komplettem Logfile an LKML. Zusätzlich zuständige
+Maintainer auf CC. Instruktionen und Anregungen der Maintainer befolgen.
+
+Linux läuft auf kleinen embedded Systemen, wie z.B. dem in der Vorlesung
+benutzten ARM basierten beagleboard, aber auch auf x86 Servern mit z.B. 64 CPUs
+und 32 GB RAM. Mit welchen Systemen und Methoden konnte diese Flexibilität
+erreicht werden? (3 Punkte) - 3 Minuten
+
+- Kernelkonfiguration mit make menuconfig / kconfig
+- Aufteilung des Kernels in core Code / Treibercode / arch spez. Code / FS Code
+- Verwendung von Algorithmen die auf beiden Enden (Server, embedded) skalieren
+
+Welche Hardware muss vom Bootloader initialisiert werden, damit ein Linuxkernel
+korrekt bootet? (4 Punkte) - 4 Minuten
+
+- Clocks für CPU, PLLs, Peripherie
+- Speicher von dem der Kernel gelesen wird
+- RAM
+- serielle Schnittstelle
+
+Linux ist ein monolithischer Kernel. Beschreiben Sie die Aufgaben des Kernels
+und markieren Sie die Aufgaben, welche typischerweise in einem Microkernel nicht
+im Kernel implementiert sind. (0.5 Punkt pro Begriff, 1 Punkt bei korrekter
+Zuordnung --> 4 Punkte) - 4 Minuten
+
+- Speicherverwaltung
+- Dateisysteme (-)
+- IPC
+- Scheduling
+- Networking (-)
+- Treiber (-)
+
+Ein von Ihnen entwickelter Kerneltreiber funktioniert nicht, welche
+Debuggingmöglichkeiten haben Sie? Beschreiben Sie 2 Methoden / Nennen Sie
+jeweils Vor- und Nachteile. (6 Punkte) - 6min
+
+- Sourcecodeanalyse
+ + der Code MUSS verstanden werden
+ - teilweise relativ kompliziert Aufrufreihenfolgen herauszufinden
+
+- Tracing (z.B. ftrace)
+ setzen von Tracepunkten, Tracer aktivieren und bei Bug deaktivieren, Trace-
+ buffer auslesen und analysieren.
+ - verändert im eingeschaltenen Zustand das Timing
+ - für einfache Fehler (z.B. off by one im eigenen Treiber) evt. zu aufwändig
+ + trace on OOPS
+ + kein messbarer Overhead falls eincompiliert aber ausgeschalten
+ + viele verschiedene Tracer verfügbar
+
+- kgdb
+ Kernel mit kgdb Support übersetzen, gdb auf 2. PC remote mit dem kgdb Prozess
+ verbinden (seriellen Schnittstelle), debuggen wie mit gdb.
+ - massive Eingriffe in das Timing. Daher für HW nahe Probleme nur sehr bedingt
+ einsetzbar
+ + intuitiv für Personen die mit gdb umgehen können
+ + Kernelsource und konfiguration muss nicht für jedes Problem verändert
+ werden.
+
+- printk
+ Dumpen von Variablennamen / Registerinhalten auf die Kernelkonsole. Versch.
+ Errorlevel können gefiltert werden.
+ - sollte nicht an jeder Stelle eingesetzt werden (IRQ Handler)
+ + da ständiges neucompilieren zeitaufwendig ist, ist man bemüht den Code zu
+ verstehen und die richtigen Dinge auszugeben.
+
+- starten eines UML Kernels in gdb
+ Es wird ein Kernel übersetzt, welcher als Prozess im Userspace läuft. Dieser
+ kann dann in gdb gedebugged werden, wie jeder andere Userspace Prozess.
+ - es kann nicht auf HW zugegriffen werden
+ + keine 2. HW zum debuggen notwendig, Entwickler PC läuft stabil weiter
+
+Das Linuxtreibermodell kennt verschiedene Treiberarten. Worin besteht der
+Unterschied zwischen einem 'platform_device_driver' und einem
+'pci_device_driver'? (4 Punte) - 4min
+
+Ein Platformtreiber muß im Boardfile explizit geladen werden, hierbei müßen IO
+Resourcen und ggf. Interuptlinie hardgecoded mitgegeben werden. Er wird für
+Geräte verwendet, welche so angeschlossen sind, dass Sie nicht automatisch
+dedektiert werden können.
+
+Ein PCI Treiber kann anhand der PCI Vendor ID und PCI Device ID vom PCI
+Subsystem automatisch geladen werden, falls eine entsprechendes Gerät am Bus
+vorhanden ist.
+
+Es ist technisch möglich ein ext3 Dateisystem mit Hilfe des MTD-block Treibers
+auf einem lokalen NAND Flash zu betreiben. Weshalb macht es keinen Sinn? (2
+Punkte) 2min
+
+- kein Wear Leveling möglich
+- journaling filesystem macht zuviele writes -> NAND geht schneller kaputt
+
+Nennen Sie je einen Vor- und Nachteil eines Threaded Interrupthandlings. (2
+Punkte) 2min
+
++ paralleles abarbeiten von shared IRQs auf Multicoremaschinen
++ Interrupts können preempted werden
+- Zeit bis zum Ansprung des Interrupthandlercodes wird verlängert
+
+In Kernelversion 2.6.39 wurde die Big Kernel Lock komplett eliminiert. Wozu
+diente die Lock und weshalb bestand Interesse die Lock zu ersetzen? (4 Punkte) 4min
+
+- Die Lock diente zur Zugriffsserialsierung auf versch. Resourcen in SMP
+ Maschinen.
+
+- Die Lock sollte durch granulareres Locking ersetzt werden, da preemption
+ während die BKL gehalten wird disabled sein muss und deshalb unnötig hohe
+ Schedulinglatenzen entstehen konnten.
+
+Erklären Sie das 'Priority Inversion' Problem und wie diese Problematik mittels
+'Priority Inheritance' entschärft werden kann. (5 Punkte) 6min
+
+Ein hochpriorer Prozess will Zugriff auf eine Resource, welche derzeit von einem
+Prozess mit ganz niedriger Priorität blockiert wird. Der hochpriore Prozess
+kann erst gescheduled werden, wenn der niederpriore die Resource freigegeben
+hat. Zwischenzeitlich wird aber ein Prozess mit mittlerer Priorität gescheduled,
+da dieser eine höhere Priorität hat, wie der Niedrige. Es wird nicht beachtet,
+dass der Niederpriore einen hochprioren Prozess blockiert. -> Priority Inversion
+
+Mittels Priority Inheritance wird der niederpriore Prozess solange auf die
+Priorität des Hochprioren angehoben, bis er die Resource freigibt. Somit ist
+sichergestellt, dass kein Mittelpriorer die Abarbeitung Freigabe verzögert.
+
+Sie starten ein Linuxsystem. Die letzten Ausgaben lauten:
+freeing memory, loading init
+Nennen Sie 4 mögliche Ursachen (2 Punkte) - 2min
+
+- der Devicenode /dev/console fehlt
+- console= Parameter in den Kernelparams nicht korrekt
+- kein Rootfilesystem vorhanden
+- Treiber für das Dateisystem des Rootfilesystem fehlt
+- keine Netzwerkverbindung bei NFS Rootfilesystem
+- Hardware welche für das mounten des RFS notwendig ist, ist noch nicht fertig
+ initialisiert -> rootwait Parameter ergänzen
+
+Sie wollen ein embedded System komplett aus dem 64 MByte großen NOR Flash
+betreiben. Beschreiben Sie, z.B. anhand einer Skizze, welche Kernelsubsysteme /
+Treiber für einen sinnvollen Flashzugriff benötigt werden und wie der Speicher
+aufgeteilt werden könnte. (nor 1 punkt, mtd 1 punkt, ubi 1 punkt,
+static 1 punkt, dynamic 1 punkt -> 5 Punkte) 5min
+
+ -----------------
+ | RFS | RFS Dateien
+ --------------------------
+ | zImage | UBIFS | kernel binary, Dateisystem
+ --------------------------
+ | kernel | RFS | 2MB UBI Vol. static, * UBI Vol. dyn.
+---------------------------------
+|IPL | UBI |
+---------------------------------
+| MTD0 | MTD1 | 256kByte, *
+---------------------------------
+| 64 MB NOR |
+---------------------------------