Sie befinden sich hier: Termine » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 4 » BST / KSS   (Übersicht)

BST / KSS

Prüfer

Wolfgang Schröder-Preikschat
Daniel Lohmann

Einordung

Diese Prüfung fand am selben Tag 30 min vor bs-2014-07-22 statt, was die hohe Ähnlichkeit erklärt.

Allgemeines

Sehr angenehme, entspannte Atmosphäre, die Prüfer geben kleine Tipps, sollte man auf dem Schlauch stehen. Man hatte das Gefühl, dass im Vornherein keine festen Fragen existieren, sondern vielmehr der Prüfer selbst am Anfang nach einem guten Anfangspunkt sucht. Von dort ab werden Gespräch und Fragen dann scheinbar „dynamisch“ entwickelt. Wie bereits in anderen Prüfungsmitschriften angemerkt wurde manchmal explizit auf das Fallen eines Begriffes gewartet, im Zweifelsfalle führt der Prüfer aber auch darauf hin („Und was wäre jetzt dann der vordere Adressteil, wenn wir mal im AuD-jargon sprechen“ - der Index)? Es lagen Zettel und Stifte aus. Am Übergang von BST zu KSS tauschten wosch und Daniel die Rollen von Prüfer und Beisitzer, die Zeit war grob 2/3 BST zu 1/3 KSS verteilt. Zwischenzeitlich gab es mal zwei kurzen Phasen, in denen wosch einige Hintergrunddetails gegeben hat. Dies schlug sich aber nicht in der Benotung wieder.

Prüfungsfragen

BST

P: Adressräume aufspannen, schützen, das Betriebssystem schützen vor den Anwendungen und umgekehrt, dazu braucht man ja eine MMU. Was benötigt man den dann weiterhin?
MMU/Adressraumdeskriptoren

P: Wie sieht so etwas dann aus?
Kommt drauf an wie die MMU aufgebaut ist

P: Welche Alternativen? Warum das eine/andere?
Segmentierung:
Kurze Erklärung was Segmentierung ist
Vorteile/Vorzüge: keine ungültigen Adressen, einfachere Mitbenutzung (vgl shared lib in segment → kein Plazierungsproblem), andere Ganularitäten
Paging
Kurze Erklärung was paging ist
Vorteile/Vorzüge: virtueller Speicher/swapping einfacher da alle Seitenrahmen gleiche Größe besitzen, illusion eines linearen Adressraums vom modell her ggf. schöner

P: Kann man die beiden Varianten kombinieren?
Pages in Segmenten:
Ja. Damit werden Segmente schöner page/auslagerbar, trotzdem Vorteil der schöneren Mitbenutzung
Segmente in einer Page:
Ergibt doch eigentlich keinen Sinn
(Erläuterung von wosch): gabs wohl mal bei einigen DEC(?)-CPUs, Vorteil ist wohl die besser einstellbare Granularität. Aber nicht sehr zeitgemäß/wichtig

P: Segmentierung hat sich ja (leider) wie es scheint nicht durchgesetzt. Also zurück zu den Datenstrukturen beim Paging. Was gibt es denn da für unterschiedliche Varianten:
lineare Seitentabelle, erklärt, in der Erklärung dann weitere Frage
P: Ok wie wird da die Adresse genau gebildet?
Skizzieren einer linearen Seitentabelle, einer adresse (kasten), Aufteilung der Adresse in Seitennummer + Offset.
wosch wollt explizit hören, dass der Vorderer teil der adresse als index in die Seitentabelle dient.
Einordnung/Bewertung der Struktur: Schlecht, weil immer die volle Datenstruktur für den gesamten Adressraum angelegt wird.

P: Ok, aber was ist wenn die Hardware Bounds-checks anbietet, also 2 Register, die die grenzen (oben und unten) der Pagetable einschränkt?
Beispielhaftes Speicher-Prozesslayout hinmalen:

	|----------------------------|
	|            CODE            |
	|----------------------------|
	|          DATEN/BSS         |
	|----------------------------|
	|            STACK           |
	|                            |
	|              |             |
	|              v             |
	|                            |
	|                            |
	|----------------------------|
	|                            |
	|                            |
	|              ^             |
	|              |             |
	|                            |
	|            HALDE           |
	|----------------------------|

Die unterschiedlichen Expansionsrichtungen sind hier problematisch.

P: Kann man das beheben? Geht das irgendwie?
4 register zur Eingrenzung verwenden

P: Ja aber das benötigt hardware support. Ohne?
(Mit Hilfe): Embedded systems, etc.: Dort wird manchmal vorab die maximale Stackgröße berechnet. Dann Layout wie oben, Stackgrenze aber fest auf Maximalwert, Halde direkt anschließend, wächst auch nach unten. Solch eine Berechnung ist aber nicht immer möglich.

P: Ok, alternative Herangehensweisen für Pagingtabellen, die dies verhindern?
Mehrstufiges paging
Wieder zeichnen (Adresse aufteilen, zweistufig im beispiel)

P: Problematik bei diesem Ansatz?
Vor allem bei 3+ stufigem Paging: Geschwindigkeit. Kann durch TLB gemindert werden.

P: Ok, jetzt hast du ja noch andere Möglichkeiten erwähnt (iirc hatte ich das garnicht, aber gut)
Invertierte Seitentabelle erklärt, wichtig dabei darauf hinzuweisen, dass sich dies nach dem realen Adressraum in den Abmessungen richtet, AID, …

P: (Frage nach den Nachteilen des Verfahrens)
Suche ggf. langsam, umsetzung in Hardware zwingend nötig:

  • Assoziativregister sehr teuer (muss ja den gesamten bestückbaren Adressraum vorsehen, Platz auf dem die ist knapp, etc.)
  • Hashing mit Kollisionsauflösung, aber in Hardware ist das auch viel Aufwand.

KSS

P: Linux ist sehr konfigurierbar. Warum ist das so, ist das gut oder schlecht?
Vorteile: viel hardware support, sehr anpassbar, vor allem Hardware. Schon schön das in vielen Szenarien betreiben zu können
Nachteile: Toolsupport, Wartbarkeit eher mittelmäßig aufgrund der Umsetzung mittels CPP, keine Separation of concerns

P: Ok, also starten wir from scratch, alles auf null. Wie geht man heran wenn man das Umsetzen will?
Versuch: andere Umsetzungsformen wie Aspekte, Generator oder OOP verwenden.

P: Das sind aber schon umsetzungen. Wir sind ja noch ganz am Anfang.
Domänenmodell aufstellen. Bestandteile des Domänenmodells aufzählen/erläutern (Domänenbeschreibung/abgrenzung, Glossary, Concept Model, featuremodel)

P: Ok, und nun haben wir so ein Featuremodel. Wie drücken wir da eine Eigenschaft aus, wie bspw. „möglichst klein“
naja, das ist nonfunctional requirement, schwer auszudrücken
(mit etwas Hilfe): Die anderen Features müssen kategorisiert werden

P: Was gibt es denn da?
Mandatory
optional
alternativen
at least one, etc (vgl. folien zu featuremodel, optionen)
Dann halt für „möglichst klein“ alle optionalen abwählen, solange nicht explizit vom Nutzer gefordert, bei Alternativen die kleinstmögliche zulässige wählen, etc.

P: Wie notiert man da jetzt, also das feature „möglichst klein“?

              |-----------|
              |     A     |
              |-----------|
              /          \
             /            \
            ●              ○
       |---------|      |-----------|
       |    B    |      | mgl klein |
       |---------|      |-----------|
        /       \                |
       /\_______/\               |
      ●           ●              | Depends on D
|-------|      |-------|         | rational: D is the smaller option
|   C   |      |   D   |         |
|-------|      |-------|         |
                    ^            |
                    |            |
                    -------------|

Vorbereitung

ca. 1 Woche. Wie schon in anderen Prüfungsprotokollen angemerkt empfiehlt es sich, die Folien zur Vorbereitung mehrfach zu lesen, manche Abschnitte sind etwas „schwergänig“ formuliert. Es wurde vor allem Verständnis des Stoffes geprüft.