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)

  • Aufräum-Release
    • Liste ergänzen. (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.
Topic revision: r22 - 18 Aug 2011, UnknownUser
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback