Release 4

Zeitrahmen: bis 16. November 2006.
Anschließend soll die Aufräum-Release angegangen werden, die Ende des Jahres fertig sein sollte.

Access Rights

• (KHoe)
• Erweiterung des IDL-Interfaces bzw. Beschluss über die Klasse für den zusätzlichen Parameter der Methoden read() bis connectCall().
  Wichtigster Punkt, weil davon auch Cosylab betroffen ist!
• Implementierung: siehe Punkt Nameservice.

Eigener Nameservice

• (KHoe)
• Funktionsmuster implementieren.
  • Erster Schritt könnte ein funktionsfähiger Nameservice sein, so dass man Client und Server ohne Änderungen im Code nur neu generieren muss, damit sie anschließend mit dem neuen Nameservice zusammenarbeiten.
• Beschluss über endgültiges Design. (alle)
• Komplettimplementierung.
• Ausfallsicherheit (fail over) des Servers berücksichtigen.

AccDevice, VmeDevice, DevMan

• (Kain)
• Implementierung eventkonnektierter Aufträge. Beachten sollte man dabei auch den Punkt zu Konnektierungen aller virtueller Beschleuniger in Server-Seite: zu tun.
• DevMan: Instanziierung von Geräteobjekten nur mit der Nomenklatur. Die Geräte holen sich die nötigen Infos mittels getLogDevAddr(), getDeviceConstants() usw. (ok)
• EquInfo in VmeDevice integrieren.
• VME-Access für CPU87 inklusive Interrupt-Behandlung in einem extra Modul (etwa VmeAccessCpu87) implementieren. (ok)
• Rest der Liste "State Changes" abarbeiten.

Lokale DB

• (LH)
• Test und evtl. Einsatz des Exchanger XML Editors. (KHoe, ok)
  • Wie können die Polynomkoeffizienten für MX und MD integriert werden? Lösungsvorschlag erarbeiten. (LH et.al., postponed)
• Das Modul Dbs muss die Methoden getLogDevAddr() und getDevConstants() zur Verfügung stellen, die vom Geräteobjekt aufgerufen werden. (ok)
• Konzept für DBRELOAD-Funktionalität erarbeiten.
  • Konstanten sollten kein Problem sein.
  • Geräte sind schwieriger. Was tun wenn das Gerät
    • neu in der DB ist,
    • nicht mehr in der DB ist,
    • noch in der DB ist, es aber eine neue Adresse oder einen neue Namen hat?

DPR-Struktur V09

• (Kain)
• Master-Status in den Systemteil des DPR (Kain, ok)
• Restarbeiten, um STATUS, ACTIV und INFOSTAT komplett gerätemodell-unabhängig zu machen. (Kain, ok)
  • ACTIV inklusive geänderter CmdCom-Parameter (nur noch die Beschleunigernummer übergeben). (Kain)
• EQMs an neue DPR-Struktur anpassen. (NN, per script)
• Strukturen mit Long-Elementen, die in Arrays einfließen, und die aus Platzgründen auf Wortgrenzen aligned sein sollen, werden (versuchsweise) explizit mit einem __attribute__ ((aligned(2))) bzw. besser mit dem VMEALIGN_2 Macro versehen. Das muss für PPC und M68k funktioniren und sollte nur in Ausnahmefällen genutzt werden. (Kain, leider geht das aber nicht so einfach. Helfen tut ein explizites attribute__((__packed)) in der Struktur an den Stellen, die ohne automatisches Auffüllen zusammenrücken sollen:

           struct {
             UWord sepp;
             ULong hans __attribute__((__packed__));
             UByte fritz;
             UWord max;
           }
        

  dabei rutscht nur hans an sepp heran, nicht aber max an fritz)
• Kochbuch überarbeiten und EQMs integrieren. (LH)

Userface, NODAL

• (GSch)
• Abstürze bei disconnect() untersuchen. (ok)
• Eventkonnektierungen einbauen. (ok)
• AccData-Wrapper von Klaus, der void-Elemente ohne Exception zurück liefert und strings in array of bytes konvertiert, einsetzen. (ok)
• Wrapper erweitern, Strukturen in array of bytes konvertieren. (ok)
• Behandlung der void-Elemente in Strukturen überdenken. (Länge des Datentyps nicht erkennbar, gibt eine Exception) (ok)
• NODAL-Funktionen LSTDM, LSTNOMEN mit Hilfe der Properties DEVDESC und PROPDESC für Geräte an PPC-GuPs implementieren. (wild cards???)

Diverses

• Tools
  • Allgemeingültige Makefiles erfinden
    • Rahmen erstellen, oder besser
    • parametrisiertes Makefile bauen, das überall einsetzbar ist. (KHoe, ok)
  • Die USRs der Version 09 (PPC-GuP) sollen mit Hilfe von vmeconfig, prepmakeusrs usw. generierbar sein. (Kain, LH)

• Properties DEVDESC und PROPDESC
  • (LH)
  • Was soll an Infos rein?
  • DEVDESC: Gerätemodell, Adresse, SE(!), ...
  • PROPDESC: Das Bisherige und min/max Werte, Einheit(en), Auflösung(en) uvm.
  • Viele Infos werden wohl optional sein (müssen).
  • Speziell auch an die Wünsche von Cosylab denken.
  • Vorschlag erarbeiten. (ok)

• Erste Produktions-Release
  • (LH)
  • Liste fehlender, notwendiger Features erstellen. (LH ok)
  • Termin für erste Produktions-Release festlegen. Start sollte in einen Shutdown fallen!

• Aufräum-Release
  • Liste ergänzen. (alle)

• SWRELOAD
  • Vorerst beerdigen? Neue shared libraries einfach durch Reboot des DevMan laden?
  • Lösung erarbeiten. Dabei dlopen(), dlsym(), dlclose(), das C++ dlopen mini HOWTO und den Artikel Dynamic Class Loading for C++ on Linux beachten. (alle)

• Exceptions
  • Gibt es noch Exceptions, die von niemandem gefangen werden und auch an keinen Client geliefert werden können, und die dadurch den DevMan zum Absturz bringen? Untersuchung der Sources, try / catch einfügen und Message ins Logfile schreiben. Z.B. Versuch mit einem asynchronen Auftrag, der bei der Ausführung das Callback-Objekt nicht mehr findet, weil es nicht mehr existiert.

• Generic Device Interface
  • (KHoe, ok)
  • Ist mit geringem Aufwand auch auf der Client-Seite einstzbar. Generisches Interface nutzt shared pointer, Klasse Device nutzt normale Pointer auf Callbacks.
  • Wird mit der Aufräum-Release erledigt.