diff options
| author | Manuel Traut <manut@mecka.net> | 2012-07-17 10:26:07 +0200 |
|---|---|---|
| committer | Manuel Traut <manut@linutronix.de> | 2018-03-16 21:39:30 +0100 |
| commit | 4fd7806b30863b20f1126007d9437cd18a1b276f (patch) | |
| tree | 03050c48c810d490b7c2d39b132f3b50be239d30 | |
| parent | 3313ef4579ea767f42a2c86d72fc971f2cbc4fd6 (diff) | |
add pruefung 2011
Signed-off-by: Manuel Traut <manut@mecka.net>
| -rw-r--r-- | pruefung.txt | 204 |
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 | +--------------------------------- |
