datenstrukturen:

- 1 x pro system:

  - TSS
    . Achtung: TSS enthlt 16-Bit-Zeiger auf I/O-Bitmap, und die ist
      pro-task! 

  - GDT (Segmentdeskriptoren)

  - IDT (physisch; es wird auch noch eine logische pro thread gehalten)

  - 2nd-level-pagetables fr kern-shared-mem

  - ram ab 0xf0000000

  - temp-mapping-cache (wird bei thread-switch gelscht)

- 1 x pro task:

  - pgtable-root-ptr (in globalem feld)
    * fr task-switch
    * fr virt-to-phys

  - pg-directory (ref'd durch root-ptr)

  - i/o-bitmap
    * fr task-switch

- 1 x pro thread:

  - tcb + kernstack

  - idt 


---------

mapping-db:

mappings fr jede physische adresse und fr jede i/o-adresse: 

  - adreraum (tasknummer)
  - virtuelle adresse in dieser task
  - parent-mapping

operationen:

  - suche eines mappings anhand von: adreraum, virt. adr., typ (memory
    oder i/o)

  - flushen eines einzelnen mappings incl. aller kinder

  - flushen aller mappings, die zu einem adreraum gehren (lschen
    einer task
    

---------

OSKIT:

  - Die <flux/base_*.h>-Header deklarieren OSKIT-vordefinierte
    Systemdatenstrukturen.  Wir benutzen diese generell nicht (auer
    in bootstrap.c), sondern bauen unsere eigenen Strukturen auf.

    Ausnahmen: <flux/base_vm.h>, <flux/base_critical.h> und
    <flux/x86/base_trap.h> werden von einigen benutzten
    OSKIT-Subsystemen verwendet (zB direct_cons_putchar()) und mssen
    initialisiert werden.

---------

Lock-free (non-blocking) synchronization:

  - Kann man DCAS(wort, version++) mit
    CAS(version++),CAS(wort),CAS(version++) simulieren?

---------

signale

- lasse threads nur durch sich selbst manipulieren -- alle anderen
  modifikationen (ex_regs, lschen beim task-lschen) werden auf
  signale als einzigen kommunikationskanal abgebildet

- signale lassen sich leicht queuen, auch non-blocking.

- signale sind synchron: der absender schlft, bis das gesendete
  signal verarbeitet wurde; die adresse des signalhandlers, der im
  zielkontext ablaufen soll, und eventuelle parameter, liegen auf dem
  stack des absenders

- signal-handler sind zwar unterbrechbar, aber nicht durch weitere signale
  fr einen gegebenen thread und nicht durch den thread selbst

---------

synchronisation der thread-manipulation

  threads sind in folgenden queues:

  - present-liste [globale ringliste?]
    hinzufgen in: 
    . thread erzeugen [von auen]
    lschen in: 
    . thread lschen (in: task lschen) [von auen]

    in der present-liste stehen threads einer task direkt
    hintereinander.  d.h. beim task erzeugen wird ausgehend vom
    erzeuger die liste bis zum ersten thread der nchsten task
    gescannt und dort eingefgt; beim erzeugen eines neuen threads in
    einer task wird nach dem erzeugenden thread eingefgt (so wird
    sichergestellt, da thread 0 immer der erste thread einer task in
    der liste ist).

    wird eine task gelscht, wird ausgehend von thread 0 der task die
    present-liste parsiert und alle threads der task gelscht.

  - ready-liste (globale ringliste?)
    hinzufgen in:
    . thread erzeugen [von auen]
    . thread-umschaltung (preemption), falls noch nicht in ready-liste (in:
        scheduler) [selbst]
    . prioritt wird gendert [selbst oder von auen; siehe unten]
    lschen in:
    . thread lschen (in: task lschen) [von auen]
    . thread-absturz [selbst]
    . scheduler findet thread in ready-liste, der nicht "runnable" ist
      [von auen]
    . prioritt wird gendert [selbst oder von auen]

    nach prioritten sortiert; entweder eine liste pro prioritt, oder
    fr jede prio ein zeiger in die ready-liste

    der scheduler sucht vom gerade preempteten thread aus den thread
    mit der hchsten prioritt oder den nchsten lauffhigen der
    gleichen prioritt. XXX

  - sender-liste (fr jeden thread (empfnger))
    hinzufgen in:
    . ipc-send [ sender ]
    lschen in:
    . timeout [ sender ]
    . ipc-receive [ empfnger ]
    . empfnger-thread wird gelscht [ von auen ]
    . sender-thread wird gelscht [ von auen ]

    hinzugefgt wird stets am ende, ausgehngt am anfang (oder bei
    timeout in der mitte).

  folgerungen:

  - wir bentigen ein tcb-flag "in-ready-list"

  ideen:

  - generalisierung: thread-operationen werden grundstzlich vom
    thread selbst (auf dessen thread-stack) ausgefhrt (und auf diese
    weise serialisiert).  soll ein fremder thread manipuliert werden,
    wird ein synchrones "signal" an den thread gesendet: eine
    signal-struktur wird auf dem stack des aufrufers angelegt und in
    die signal-liste des fremden threads eingehngt.  dann wird der
    thread geschedulet.  bevor ein neu geschedulter thread zum alten
    kontext zurckkehrt, werden zunchst der reihe nach alle signale
    ausgehngt und abgearbeitet.

    signalisierte threads werden runnable (XXX was ist der zustand
    nach der abarbeitung des signals?  knnte signalabhngig sein ->
    alten zustand in signal-struktur abspeichern) und laufen mit der
    prioritt des hchsten signalisierers (oder es gibt irgendeinen
    anderen priority-inheritance-mechanismus).  XXX

    wir bentigen also eine weitere liste:

  - signal-liste (fr jeden thread):
    hinzufgen in:
    . manipulation eines fremden threads [ von auen ]
    lschen in:
    . scheduler nach umschaltung [ selbst ]
    . empfnger-thread wird gelscht [ von auen ]

    signale werden (im gegensatz zu ipc) gestackt (und nicht
    gequeuet).  eingefgt und entfernt wird also immer am beginn der
    liste.

----------

scheduler

  - kann thread selektieren, wenn: 
    . in ready-queue, und
    . thread_running

----------

gcc 2.7 kann offenbar keine template-inline-funktionen auch inline
einbinden.

----------

denkbare erweiterungen der l4-schnittstelle

* sicherheitsproblem:  recyclen von kacheln, die noch in treibern fr
		       dma-zugriffe benutzt werden

  lsung: treiber locken kacheln exclusiv (voraussetzung: treibertask
	  hat i/o-privileg; nebeneffekt: liefert physische adresse der
	  seite).  lock verhindert weiteres mappen der kachel (aber
	  nicht flushen).

* problem: beim task/thread erzeugen kann man keine prio angeben; das
	   geht erst, nachdem der thread potentiell schon losgelaufen
	   ist

  lsung:  weiterer parameter

----------

task lschen:

- suche ersten thread der task in ready-liste

- ausgehend vom ersten thread, markiere alle threads der task als
  "dead" (durch senden eines signals).  da wir von vorn beginnen, neu
  erzeugte threads aber immer nach dem erzeugenden thread eingequeuet
  werden, erwischen wir alle threads, auch wenn die task zwischendrin
  noch mal geschedulet wird.

- wende verfahren rekursiv auf alle subtasks der task an.  (wir
  erwischen alle, denn es knnen keine mehr dazukommen, da wir alle
  threads des chiefs gekillt haben.)  threads von subtasks finden wir
  in der present-liste vor dem ersten thread der chief-task.

- gebe resourcen einer getteten tasks frei, wenn sie keine kinder
  mehr hat


. problem: wenn threads einer subtask geschedulet werden und mit task
  kommunizieren wollen, schlgt ipc fehl.  schlimm?


-----------

