fail/doc/todo.txt

==========================================================================================
Verrückte Ideen
==========================================================================================
 - aufeinander aufbauende Events (Backend-spezifisch <- generisch, oder mehrere
   Einzelevents gebündelt in ein einzelnes abstraktes ["Crash", HLT mit
   abgeschalteten Interrupts])
   * lösbar als Callback-"Experimente", die selbst Events auslösen?
   * Synthese komplexerer Events
 - Events fuer besondere Instruktionen (HLT?)
 - Backend-Schnittstelle (z.B. direkte Anbindung an Simulator vs.
   GDB-Schnittstelle zu Simulator vs. Anbindung an reale HW) von
   Backend-Architektur (welche Register gibt es, wie breit ist der
   Datenbus, welche Traps können ausgelöst werden, etc.) trennen


==========================================================================================
FailBochs-Bausteine TODO
==========================================================================================
Wer gerade an was arbeitet, steht in Klammern hinter dem TODO.

Bochs:
 - Determinismus: Wie kann für Mikroexperimente sichergestellt werden, dass
   externe Ereignisse (Timer, Eingang von Netzwerkpaketen, ...) reproduzierbar
   zum selben Zeitpunkt eintreffen? (rh)
   - Interrupts teilweise oder komplett sperren
   - optional: Interrupts auslösen

Abstraktionen:
 - Traces: geeignet kapseln, in einer Sequenz von protobuf-Nachrichten statt
   einer großen rausschreiben/laden (rh)
 - Endianness?
 - Merkmalmodell von Implementierungsdetails trennen (hsc)
   -> automatische Konfigurierung anhand Experimentauswahl
   -> Annotierung von Experimentcode, automatisches Nachladen von Aspekten
 - einheitliches Namensschema für Backend-Beeinflussungen (Interrupt-Synthese,
   Interrupt-Unterdrückung, Speicher schreiben, Register schreiben, ...) finden
   -> "Fehlerinjektion" ist das ja nicht immer
 - (Allgemeine) Testfälle / Regression-Tests
   -> Modifikationen an FAIL* sind damit leichter zu verifizieren

Events:
 - 

Parallelisierung:
 - Momentan landen initial *alle* Parametersätze im Speicher.  Sobald das viel
   mehr werden, wird das eventuell eng.
   -> BoundedSynchronizedQueue basteln, Kampagne blockiert dann, wenn die voll ist
   -> eingehende Resultate nicht in der Kampagne "verarbeiten" (rausschreiben)
      -- sonst bekommen wir dasselbe Problem mit der Queue der Resultate;
      stattdessen z.B. die Idee der ExperimentDataStorage weiterverfolgen,
      Ergebnisse werden asynchron zur Kampagne weggeschrieben
      (oder: Zweiteilung der Kampagne vornehmen, "Verarbeitung" in eigenem
      Thread)
 - coolcampaign fährt momentan ziemlich Achterbahn bei RAM-Benutzung
   -> Grund analysieren, ggf. beheben (Ressourcenverwaltung? Threadpool?)
 - warum skalieren die Experimente/s nicht (ganz) linear mit der Anzahl der
   Cores auf einer Maschine?  Jobserver-Problem, oder lokal Contention auf dem
   Client (Kernel, Disk-IO)?
   -> mal Experimente ohne Kommunikation laufenlassen, Durchsatz messen
   -> mal mit mehreren Maschinen durchmessen
 - JobServer Statistiken ausgeben lassen, dafür keine Meldung mehr bei jedem Auftrag
   * Anzahl Hosts
   * Anzahl Clients (momentan ununterscheidbar ...)
   * Aufträge pro Sekunde
   * ETA bis Kampagne komplett
 - Client/Server-TCP-Verbindungen aufrechterhalten
 - die Möglichkeit schaffen, im Server mehr Informationen über einen Job
   vorzuhalten (und zu loggen), als man an den Client kommuniziert
   -> bei Fault-Space-Pruning hat man im Server Äquivalenzklassen, aus denen
      man nur einen einzelnen Parametersatz auswählt und dem Client zum
      Ausprobieren gibt; die Informationen über die Äquivalenzklasse müss(t)en
      nicht über die Leitung, werden aber am Schluss zur Auswertung gebraucht
 - Build-ID in control message tatsächlich generieren und verwenden!
   - einfacher, aber nicht in allen Fällen wirksam: Server generiert zur
     Laufzeit "Session-ID"; falls bei Client-/Server-Kommunikation diese nicht
     mit der vorherigen übereinstimmt, terminiert der Client automatisch
     * Problem 1: hilft nicht, wenn der Client gerade neu gestartet wurde
     * Problem 2: wenn das viele Clients tun, landen sehr viele unbearbeitete
       Jobs in der Aktiv-Queue auf dem Server

Implementierungsdetails:
 - einheitliche Fehlerbehandlung
 - einheitliches Logging (Loglevels?), Ausgaben (z.B. im Bochs-Controller,
   siehe BochsController::save) vereinheitlichen, evtl. zusätzlich via
   (Non-)Verbose-Mode(s)
   -> "Ausgabesystem", "Logger"

Effizienz:
 - getrennte Queues?
 - Queue-Suche optimieren (Hashes, Sortierung, ...)?
 - boolean/Counter für Events (um Durchlaufen der Queue zu verhindern)?
 - Dynamic AspectC++ ausprobieren
 - Löschliste in EventList via Hashing implementieren (o.Ä.)?

Buildsystem:
 - (mittelfristig) in cmake nur wirklich Build-spezifische Dinge konfigurieren
   (verwendeter Compiler, Installationsverzeichnis, ...), den Rest in einem
   brauchbaren Konfigurationswerkzeug mit Ausdrucksmöglichkeiten für
   Merkmalmodelle, Abhängigkeiten, Mehrfachauswahl etc. (kconfig?)
   * Bochs / OVP sind Alternativen, nicht beide anschaltbar (?)
 - Hinzufügen eines neuen Experiments konkreter dokumentieren (how-to-build.txt?)

Dokumentation:
 - Änderungen im Klassendiagramm nachziehen (hsc)
 
Erledigt:
 - alle Events mit Zähler versehen, so dass sie erst bei Erreichen der 0 feuern
   * z.B. erst nach dem 5ten Mal Lesen von Adresse X auslösen
 - Bereiche von Instruction-Pointern
 - Wrapper für häufig auftretende Experimentmuster, z.B. einzelnes Event
   anlegen und dann genau darauf warten
 - Wildcards für beliebige Instruktions- bzw. Speicheradresse (ANY_ADDR, siehe Event.hpp),
   inkl. Anpassung des ausgelösten Events
 - Registerzugriff aus dem Experiment-Controller, RegisterBitflip vorbereitet
 - Auslösen von Reboot (rh)
 - Auslesen von Register- und Speicherzustand (Kontext Golden-Run-Vergleiche etc.)
 - Coroutinen-Bibliothek (oder getcontext/setcontext) statt Threads+Synchronisation?
 - Bitflips in Register
 - nach Eintreten eines Events wird das Event- (oder FI-)Objekt mit
   Detailinformationen befüllt
   -> insbesondere bei "Wildcards" (ANY_TRAP) will man ja im
      Experimentablauf wissen, was jetzt eigentlich passiert ist
 - Event-Aspekt zur Kommunikation mit dem Gastsystem fertig stellen (siehe events/GuestSysCom.ah)
 - Bochs-Spezifika von Bochs-unabhängigen Codeteilen trennen
   -> Simulator-Abstraktionsschicht
   -> Schnittstelle für Informationen über Plattformspezifika, z.B. Register + Bitbreiten
   -> Bochs-spezifische Aspekte leiten nur noch Kontrollfluss um,
      Implementierung von Ereignissen separat
 - (sofern möglich) Ereignisse von FI trennen
 - Scattering-Graphik, (Python-)Skript (ab)
 - ohne GUI bzw. gesetztem $DISPLAY lauffähig? (rh)
 - Save (rh):
   - Zielverzeichnis anlegen, falls nicht existent
   - Fehlermeldung, falls Zielverzeichnis nicht schreibbar
 - FI-Jobs gibt's nicht mehr, überall rauswerfen (ab)
 - Traps und Interrupts (alle, oder Match auf beliebige Teilmenge) 
   (Aspekte existieren bereits. Matchen auf beliebige Teilmenge der Traps ist noch nicht moeglich)
   (rh)
 - die schlimmsten Speicherlecks in Bochs eliminieren (rh)
 - Event-IDs als Identifikationsmittel für Events auf den zweiten Platz verweisen
   -> IDs gibt's weiterhin (getId()), aber z.B. waitAny() liefert einen Pointer (ab)
 - Brauchen wir eigentlich IDs als Handles für Events, oder genügt es nicht
   eigentlich, die Event-Objektadresse zu verwenden? (ab)
 - Event-Match-Schleife von Event-Feuer-Schleife trennen (ab):
   - erst alle Events, die aktuell matchen, sammeln (Code ggf. spezifisch für die Ereignisart)
   - dann sequentiell feuern (Code zentral in SimulatorController)
   -> keine Probleme mit nachträglich hinzukommenden Events
   - dann leider immer noch Probleme mit nachträglich entfernten Events
   -> siehe fail/experiments/coolchecksum/experiment.cc FIXME am Ende
   -> Lösung: Löschliste
   - ggf. zusammen mit Datenstruktur-Implementierungsdetails-TODO (s.u.) angehen
 - FailConfig.hpp in cmake-config einbinden (genauso behandeln wie experiments.hpp!)
   -> generierte Datei landet in Buildtree, wird nicht mehr eingecheckt
 - variant_config.h in cmake-config einbinden (genauso behandeln wie experiments.hpp!)
   -> generierte Datei landet in Buildtree, wird nicht mehr eingecheckt
 - EXP*-options nur einmal in config/, nicht in drei verschiedenen Dateien
   (config/CMakelists.txt, config/experiments.hpp.in,
   experiments/CMakeLists.txt)
 - zum Verpacken in ExperimentData-Nachrichten Register<->String-Konvertierung
   vereinfachen (ab)
 - Speicherzugriffe: bei Instruction Fetch?  INC $Adresse?  CALL?  PUSH?
   PUSHF?  Interrupt? (ab)
 - Timer (Bochs: basierend auf bx_pc_system.register_timer()) für "echte"
   Timeouts (die auch dann greifen, wenn die CPU z.B. in einem CLI/HLT steht) (ab)
 - Client-Timeouts untersuchen, Server-Implementierung tunen?  Retries im Client? (ab)
 - unbeantwortete Jobs am Ende einer Kampagne erneut vergeben (ab)
 - Namespace Confusion: aufräumen (ab)
 - Verzeichnisstruktur umstrukturieren und aufräumen (ab)

==========================================================================================
Theorie TODO
==========================================================================================
 - Problem Fork von FI Tools -> Merging eklig.
   -> Liste mit konkreten Beispielen 


==========================================================================================
FailOVP-Bausteine TODO
==========================================================================================
Wer gerade an was arbeitet, steht in Klammern hinter dem TODO.

Abstraktionen:
 - save/restore implementieren -> Speicher-, Register-, Timer-, ??- Zustaende 

Sonstiges:
 - Sections aus ELF Datei extrahieren, entsprechende Speicherbereiche (generisch) anlegen (rz)
 - Symbole aus ELF extrahieren -> Adressen von globalen Objekten/Funktionen in Experimenten angeben (rz)
 - Prozessormodell per cmake cleanen und neu bauen (mh)
 - CiAO ELF in OVP ausfuehren

Erledigt:
 -