Code Rework

Zeitrahmen: vor dem Start der Arbeiten für Release 6

Zu tun

• Die Dokumentation für die 'USR-Bibliothek' (USR-Support, EquInfo usw.) sollte bald online gestellt werden. (Kain)

• Wo sind noch Stellen mit [tbs] oder Ähnlichem im Code? Was muss da getan werden? (Alle)

• Beendet sich ein ConnectThread selbst und nicht über AccDevice::disconnect(), weil z.B. der Ausführungszähler (ConnectThread::_con.count) auf Null heruntergezählt wurde, dann wird der Thread zur Zeit (28.Jul.05) nicht aus der Liste (AccDevice::_connections) ausgetragen. Das ist ein Fehler! Aber wie kommt der Thread überhaupt an AccDevice::_connections dran? (KHoe)

• Wo überall noch wird ein new Xxx gemacht aber kein passendes delete dazu? (LH)

  Es scheint alles soweit ok zu sein, bis auf folgende Ausnahmen:

  • Im Projekt accdevice sollte noch mal jemand über die cc-Files gucken. Meiner Ansicht nach ist da alles ok, aber es ist etwas verzwickt zu erkennen. (KHoe, Kain)
    • Request- und ConnectThreads sind von omni_thread abgeleitet und werden detached gestartet, was bedeutet, dass sie sich selbst komplett beenden, wobei auch der Speicher freigegeben wird.
    • Für Singletons wird nur einmal Speicher angelegt, der spätestens mit dem Ende des Prozesses freigegeben wird. Da braucht's kein delete.
  • Im Projekt devman fehlt mir etwas der schnelle Durchblick. Da sollte Peter noch mal gucken. (Kain)

---

Erledigt

• Die Methoden requestXxx() und connectXxx() in accdevice.cc machen ein new ZzzThread. Aber wer macht das delete? Oder passiert das automatisch, wenn der Thread zuende ist? Also beenden sich die Threads von selbst, wenn die main-loop verlassen und das Programm zuende gelaufen ist? Oder muss man in der Liste AccDevice::_connections bzw. AccDevice::_requests einen auto_ptr benutzen, um auf die Threads zu zeigen? (KHoe)

  Wenn man das delete(ConnectThread*) in AccDevice::disconnect() selbst machen muss, ist zu beachten, dass man natürlich erst löschen darf, wenn der Thread zuende gelaufen ist. Ansonsten würgt man ihn mitten im Lauf ab. Das Warten auf das Thread-Ende geht mit join(). Aber woher weiß disconnect(), welcher Thread gejoined wurde und nun gelöscht werden kann? Womöglich einfach std::tr1::shared_ptr benutzen. Siehe z.B. Seite 157 in "Effektiv C++ programmieren" (KHoe)

  Ich verstehe den Code aus der omnithread (posix-Teil)so, als ob der Thread sich selbst zerstört, wenn er zuende gelaufen ist (KHoe)

• Auf den asl-Rechnern wird mittlerweile in /var/log/equ/messages geschrieben, aber die tägliche Rotation tut noch nicht. (KHoe)
  • ok! Tut.

• Warum geben (viele) Methoden eigentlich einen Pointer auf ein Objekt zurück und keine Referenz? Ist Pointer nicht bad old style? Schreibt man z.B. statt alarmHandler()->send(alarm); nicht besser alarmHandler().send(alarm);? (LH)
  • ok! In der CodingForWindows.

• Ebenso über const (oder nicht) nachdenken, besonders bei der Deklaration von Methoden. Die Angabe von const bei Methoden bedeutet, dass die Methode nichts am Objekt (seinen Attributen) ändert. (LH)
  • ok! Da, wo's wichtig war, erledigt.

• Alle Methoden einer Klasse sollen mit einer Info versehen werden, ob sie eine Exception werfen oder nicht. (LH)
  • ok! Da, wo's wichtig war, erledigt.

• Alle Quellen, die eine sehr persönlich geprägte Formatierung haben, sollten mit AStyle reformatiert werden. Vorher noch mal gucken, ob die AStyle-Einstellungen bereits unserem Style-Guide entsprechen. (Da sollte mal noch eine kleine Anpassung stattfinden.) (Alle), speziell (KHoe)
  • ok! Auch in der CodingForWindows.

• Mindestens die Methoden read(...) bis connectCall(...) in accdevice.hh|cc müssen noch mit throw(AccDecException) versehen werden.
  • ok! Auch const für verschiedene Methoden ergänzt, ebenso in den Dateien *-interface.hh. (LH)

• Namespaces werden nicht komplett importiert, obige Formulierung, wie z.B. wie using namespace std;, ist verboten. Statt dessen muss man also entweder std::string x; schreiben, oder string explizit mit using std::string importieren.
  • ok! Durchgehend implementiert.

• Immer #include <abc.de> schreiben, nicht #include "abc.de".
  • ok! Durchgehend implementiert.

• Namespaces: Festlegungen
  • Es gibt keine Deklarationen mit using... in den Default-und den Therapie-USRs.
  • Verwendeten Klassen, Methoden usw. dürfen nicht abhängig sein von Namespace-Deklaraionen (using...) in den inkludierenden Sources, z.B. mx-usrs.cc.
  • Alle verwendeten Klassen, Methoden usw. werden explizit mit dem notwendigen Namespace angegeben, also etwa ...DeviceAccess::AccData....
  • ok! In der CodingForWindows.

• Überall, wo noch cout << <msg>... oder cerr << <msg>... benutzt wird, muss statt dessen eine Meldung ins Logfile geschrieben werden.
  • ok! auf der Server-Seite: Fehlermeldungen gehen (auch) ins Logfile. Es gibt aber weiterhin einige cerr- bzw. cout-Outputs, z.B Startmeldungen des DevMan. Diese werden auf dass Null-Device umgeleitet, wenn Devman per Service gestartet wird.
  • ok! auch auf der Client-Seite.

• Prinzipiell noch mal über public, protected, private nachdenken.
  • ok! Ist in die CodingForWindows eingeflossen.

• Während der Abarbeitung der Punkte wird eine CodingForWindows erstellt, die Punkte enthalten soll, worauf man bei der Codierung achten soll.
  • ok! Hier ist die (angefangene) CodingForWindows.

• connect.hh: Alle "Lese"-Methoden sollten nur dann etwas zurück liefern, wenn der "ConnectType" dazu passt. Ansonsten Exception werfen.
  • ok! Dazu u.a. eigenes connect.cc erfunden und die Makefiles angepasst.

• Namespaces und Default-USRs. In default-usrs*.hh|cc und therapy-*usrs.hh|cc sind keine Namespaces implementiert. Die bekommt man "automatisch" durch das Inkludieren dieser Dateien in z.B. mx-usrs.cc.

  In diesen Quellen findet man aber Zeilen wie using namespace DeviceAccess oder ...DA::AccData.... Zur Klarheit wird festgelegt:

  • Es gibt keine Deklarationen mit using... in den Default-und den Therapie-USRs.
  • Verwendeten Klassen, Methoden usw. dürfen nicht abhängig sein von Namespace-Deklaraionen (using...) in den inkludierenden Sources, z.B. mx-usrs.cc.
  • Alle verwendeten Klassen, Methoden usw. werden explizit mit dem notwendigen Namespace angegeben, also etwa ...DeviceAccess::AccData....
  • ok! implementiert

• In default-structtypes.hh und therapy-structtypes.hh (evtl.) auch die Deklarationen und Definitionen mit den neu erfundenen Subklassen versehen.

  Außerdem sollten dringend rein die für alle gerätemodell-spezifischen Properties MEDDATAS, MEDDATAI und MSTDATAS gleichermaßen gültigen Parameterbeschreibungen.

  • ok! Erledigt durch 'XML-USRs'.

• Verwendung von CORBA::string_dup() und CORBA::duplicate() bedenken. An welchen Stellen im Code ist das notwendig aber noch nicht eingebaut?
  • ok! Ist kein Problem, wenn man die *_var -Typen von OmniORB benutzt. Ansonsten ist das Problem mittlerweile auf die *-corba.cc -Dateien beschränkt.

• In gm-usrs.cc gibt es die Funktion addUsrs(). Diese wird im Konstruktor von GmDevice aufgerufen. Sie enthält wiederum Aufrufe wie z.B. ua.addUsr(new ReadVoltS(vd));. Wenn das Geräteobjekt gelöscht wird, was passiert dann mit den mit new angelegten USR-Objekten? Die müssen auf jeden Fall gelöscht werden! Wer macht das? Ist das in der Klasse UsrSet schon implementiert?
  • ok! UsrSet hat nun eine Methode clean(), die alle USRs aus dem Set entfernt und dabei auch ein delete(usr) aufruft. Diese Methode wird im Destructor von UsrSet aufgerufen - der (hoffentlich) aufgerufen wird, wenn das Geräteobjekt gelöscht wird. Der UsrSet-Destructor ist virtuell. [13.Dez.2006]

• Die Abstürze des Userface nach disconnect() sind weg. Ein Fehler in AccDevice führte dazu, dass nach der Diskonnektierung noch eine Antwort (an Userface) geschickt wurde. Das kann aber in Ausnahmefällen auch in Zukunft mal passieren. Dann darf/sollte Userface nicht abstürzen.
  • ok!

• connect.hh: Die "Schreib"-Methoden sollten die Parameter auf vernünftige Werte testen. Ist delta-t-min = 100ms für eine periodische Konnektierung in allen Fällen ok?
  • ok! Wird nicht hier, sondern auf der Server-Seite gewährleistet. [9.Jan.07]

• connect.hh: Methoden "event()" und "vrtAcc()" entsprechend "count()" usw. erfinden.
  • ok! [9.Jan.07]

• Methoden, die einen Pointer zurück geben, sollen im Normalfall eine Exception (mit ODA_NULLPOINTER) werfen, wenn der Pointer NULL ist. Ausnahmen sind natürlich möglich, wenn es Sinn macht, sollten aber gut dokumentiert sein.
  • ok! [15.Jan.07]

• Was passiert mit Exceptions in RequestThread und ConnectThread? Die Exceptions der USR werden abgefangen und an den Client weitergereicht. Was aber, wenn z.B. readResponse() eine Exception wirft, weil der Callback des Clients nicht mehr existiert? Das muss auch abgefangen und entsprechend geloggt werden (in accdevice.cc).
  • ok! [15.Jan.07]

• Was passiert, wenn man in einem Thread eine Exception wirft? Wo landet die, wenn es keinen expliziten Abnehmer gibt?
  • ok! Siehe oben drüber. [15.Jan.07]

• Was passiert, wenn ein dbs-File illegales Format hat? Die Methode getDevConstants() (oder wer parsed die Datei?) muss eine Exception werfen und eine Fehlermeldung ins Logfile schreiben.
  • ok! Das wird bemerkt. [15.Jan.07]

• Die allgemeinen Makefiles, aber auch die von vmeconfig generierten, funktionieren nicht mit den Targets clean und distclean, wenn in den *.d-Files abhängige Dateien stehen, die es nicht gibt, etwa weil xyz.hh auf ein anderes Directory umgezogen ist. Klaus will noch mal nachdenken.
  • ok! Mit "make -k clean" aufrufen.

• Ich glaube gerade zu sehen, dass auf den PPC-GuPs drei Log-Dateien geschrieben werden, die das Selbe enthalten, nämlich /var/log/equLog/debug, /var/log/equLog/error_log und /var/log/equLog/messages. Ist das Absicht? Ist das sinnvoll? What happend?
  • ok! Das ist unter Linux so.

• Welche Tools werden benötigt, welche müssen angepasst werden?
  • vmeconfig, prepmakeusrs, prepmakeeqms, evtl. prepmake
  • genusrs, relusrs
  • geneqms, releqms
  • cdcpu, cdeqp, cdsys
  • ecload
  • genmsg, getmsg
  • ok! Alle bisherigen Tools angepasst bzw. neu erfunden. Alles, was man für die GSW braucht, ist da.

• Zumindest beim Generieren von Geräte-Software, also USRs und EQMs, sollte der Output von `make' stark reduziert werden. Im Moment sind die wichtigen Fehlermeldungen nur schwer zu sehen. Ein Output wie unter V08 ist erstrebenswert.
  • ok! Erledigt.

• Die Funktion "getdomainname()" muss sowohl auf den asl7xx-Rechnern als auch auf den PPC-GuPs "acc.gsi.de" zurück liefern. Im Moment bekommt man auf asl nur "acc" und auf den PPCs "(none)" zurück! Was zurück kommt, hängt wohl von einer Linux-Einstellung ab.
  • ok! In getHostName() mit gethostbyname(host) erledigt.

• USRs V09: Es muss noch überlegt werden, wohin private bzw. Testversionen kopiert werden sollen, damit sie vom PPC-GuP aus zugänglich sind, aber nicht die freigegebenen (released) Versionen überschreiben. Mögichkeit: Nach /usr/local/acc/eldk/ppc_82xx/usr/local/scratch/eqp kopieren und den Link in /usr/local/acc/eldk/<GuP>/opt/acc/cpu passend setzen.
  • ok! So wird's gemacht. Dazu das Script copyusrs erfunden.

• Das Download von EQMs V09 sollte, neben anderen Möglichkeiten, genauso funktionieren wie für V08.
  • ok! Wird nun mit ecload.py gemacht.

• Müssen die Produktionsverzeichnisse, die vom asl-Cluster aus gesehen /usr/local/acc/production/vme heißen, auch von den PPC-GuPs aus erreichbar sein? Oder wie sind diese für V09 organisiert? Und welche Tools müssen dann darauf angepasst werden (z.B. cdcpu, cdeqp usw.)?
  • ok! Verzeichnisse sind festgelegt und werden im Kochbuch näher erklärt. Tools sind angepasst.

• Um an Informationen des devman von xxx-device-Seite aus kommen zu können, sollte man noch eine Klasse (als singleton) basteln in der über Methoden die notwendigen Informationen des devman erreicht werden können. (z.B. getDevManName())
  • ok! Implementiert im Device Support Interface.

• Make für USRs mit vmeconfig usw.
  • ok!

• Festlegen, was genau bei einer Release geschehen muss und die entsprechenden Tools, vergleichbar relusrs bauen.
  • ok!

• Wird irgendwo getestet, ob das GmDevice bzw. die gm-usrs auch zu den EQMs passen, die auf der SE läuft, auf der das Gerät, bzw. dessen Adresse, gefunden wurde?
  • ok! Wird nach dem Laden des jeweiligen gm.so getestet.

• Die Version im Dateinamen sollte genau der USR-Version entsprechen. Also mx.so.09.12.03 statt mx.so.9.12.3.
  • ok! So isses.

• Die Underscores in den PPC-GuP-Namen sollten wir uns sparen, also kg1cg77 statt kg1cg77_.
  • ok!

• DevMan schmiert ab, wenn der Client-Callback durch einen Fehler oder z.B. Ctrl-C abgebrochen wird. Die Fehlermeldung des DevMan am Terminal ist dann einfach nur "Aborted". Das muss abgefangen werden.
  • ok! stürzt nicht mehr ab.

• Mal testen was passiert, wenn auf verschiedenen SEs sich die Gerätekonfiguration ändert, also Bus von SE 2 nach SE 3 umhängen, Init SE 2, Init SE 3, ... Ist in jeder Phase alles ok bzw. wie erwartet auf dem GuP?
  • ok! Scheint zu funktionieren

• Automatischer Start des DevMan auf den PPC-GuPs. Auch automatischer Restart?
  • ok! Sollte für Runlevel 345 automatisch gestartet werden, aber noch ungetestet

• Auf den PPC-GuPs sollte man sich als normaler User einloggen können. Nur als root ist auf die Dauer gefährlich. Das bisherige root-Passwort sollte geändert werden.
  • ok! Useraccounts mit Standard-Passwort eingerichtet, bitte Passwort ändern
    Änderung root-Passwort nach Ankündigung

• EC-Properties implementieren.
  • ok! Alle EC-Properties sind implementiert.

• Wollen wir das Generieren eines Listings nicht langsam aufgeben, oder wenigstens als Option in vmeconfig wählbar machen?
  • ok!

• Die im GuP-Namen verdrahteten Knotennummern in Hex machen nicht mehr so viel Sinn für PPC-GuPs. Weglassen? Stattdessen was nehmen? Die Knotennummer ist das unterste Byte der Internetadresse?
  • ok! Nummer wird durchnummeriert.

• Ausfall- und absturz-sicherer DevMan.
  • ok! (vorerst)

• Einbau der Event-Konnektierungen.
  • ok! Erledigt.

• Das Logging nach /var/log/equLog sollte so eingerichtet werden, dass für jeden neuen Tag ein neues Logfile angelegt wird (log rotate daily). Das Directory soll /var/log/equ heißen, nicht /var/log/equLog.
  • ok! Erledigt.

• Die Therapie-USRs tun noch nicht richtig. Fehler/Probleme beseitigen und ausführlich testen.
  • ok! Erledigt.