 |
|
- Jetzt (29.Jan.08), wo so langsam die PPC-GuPs in Betrieb gehen, sollten sich nicht mehr jeder (BELer) unter 'root' einloggen können, sprich das Root-Passwort kennen. Jeder sollte sich unter seinem Namen einloggen können und zur Not 'sudo'-Rechte haben.
- Möglichst bald (ab Q2/2008) soll
ELDK 4.0mitLinux 2.6eingesetzt werden. Ein passendesBSPfür dieCPU87ist noch zu besorgen.
- Trotz der Erweiterung der Usr-Klasse um das Fangen von Exceptions und deren Umwandlung in AccDevExceptions, gibt es noch immer ein Problem. Passiert in der USR ein arthmetischer Fehler, z.B. Division durch 0, wirft der G++ keine Exception, sondern bricht das Programm ab. Die Behandlung solcher Fehler ist im C++-Standard nicht definiert, jeder Compiler darf machen was er will. Wie der Devman auf sowas reagiert, muss ich erst noch testen. Was kann man tun? In einem Handler anfangen? Oder wie? Jedenfalls darf der Devman nicht abstürzen!
- Evtl. eine Devam-Property
RENOTIFYerfinden, die alle Geräte (-objekte) noch mal beim Nameservice bekannt gibt. Ist - in seltenen Fällen - eventuell nötig, wenn dieser Rebootet wurde und sich vorher nicht alles merken konnte.
- Gibt es zu einem Geräteobjekt kein zugehöriges Gerät auf der SE, dann bekommt man z.B. von connectRead() eine ODA-E-NULLPOINTER-Exception zurück. Das ist wenig aussagefähig! Besser wäre ein DEV_OFFLINE oder DEV_UNKNOWN. Das kann man aber nicht direkt in accdevice.cc implementieren, weil dieses für alle Geräte gilt, nicht nur für VME-Geräte.
- Resourcen-Verbrauch auf PPC-GuP evaluieren.
- Die
cancel()Problematik besteht weiterhin! Im Moment hat der Aufruf keine Funktion.
- Ist ein asynchroner Auftrag beendet, weil
cancel()aufgerufen wurde, soll nochmal das Callback des Clients über die Methodeexit()mit entsprechender ODA-Message aufgerufen werden.Sieht eigentlich so aus, als wollte man das für die
requestXxx()-Methoden nicht implementieren.
-
AccDevice::cancel()ist nicht komplett implementiert. Es steht noch die Frage, wie man überhaupt einen "pendig request", der ja irgendwo im Zustand "blocked" hängt, beenden kann. Eigentlich geht doch nur, ein Flag zu setzen (exit = true), so dass beim späterne Weiterlaufen des Threads keine Antwort mehr an den Client geht. Stattdessen ist womöglich ein Eintrag ins Log sinnvoll.
- Die Links für die zu ladenden USR shared objects findet der DevMan unter /opt/acc/cpu. Das gilt für die PPC-GuPs, muss in Zukunft aber auch für die X86-GuPs gelten. Dort gibt es zur Zeit dieses Directory noch nicht.
Man sollte mal überlegen, ob das Eine oder Andere bisher fest Verdrahtete, wie z.B. /opt/acc/cpu, nicht besser über Umgebungsvariablen realisiert werden sollte.
- DevMan sollte noch eine Property
USRVERSbekommen, damit das Nodalprogrammvme_softwarefunktioniert.
- In accdevice.cc kann man statt
usrSet()->findUsr(...)auchusrs().findUsr(...)schreiben. Aber dann bekommt man beim Zugriff auf eine USR eine "Property not found"-Exception zurück. Warum?Schreibt man
const Usr* usr = usrSet()->findUsr(...), also mitconstund ohne Typecast, dann meckert der Compiler die folgende ZeileAccDevRetStatus ret = usr->write(...)an, weil damit dasconstdiscarded würde. Warum? Weil doch eigentlichUsr* const usr = usrSet()->findUsr(...)gemeint ist, oder?
- Dran denken, dass evtl. auch Supergeräte implementiert werden müssen, die nach außen so aussehen müssen, wie normale Geräte, aber intern mehrere echte Geräte gleicher oder unterschiedlicher Gerätemodelle vereinen.
Mal versuchen ein Supergerät zu bauen, das zwei "normale" Geräte beinhaltet.
- Was tun beim Abräumen eines Geräteobjekts?
- Konnektierte Aufträge beenden. Anwendungen Bescheid geben. SEs Bescheid geben bei Eventkonnektierungen. Ist implementiert!
- Was ist mit noch laufenden USRs, die z.B. gerade auf eine Antwort einer SE warten?
- Auf belx04 (NFS-Root auf asl710) konnte man kein Kernel-Modul nativ kompilieren, weil ein Include (cpu86.h) nicht gefunden wurde. Das
#include <platforms/cpu86.h>steckt in der Datei/lib/modules/2.4.25/build/include/asm/mpc8260.h, die womöglich von Denx kommt, oder? Dieses Include wird jedenfalls auf/lib/modules/2.4.25/build/include/platforms/erwartet (so ist's zumindest auf belx05), liegt aber auf/lib/modules/2.4.25/build/arch/ppc/platforms/. Da es das Directory.../include/platforms/gar nicht gab, habe ich es erzeugt und (bisher nur) die *.h-Files von.../arch/ppc/platforms/dort hin kopiert. Nun tut's.Wenn ich mich recht erinnere, dann hatten wir das gleiche Problem auch auf den belxxx-PPC-Rechnern, als sie NFS-mäßig noch alle von belx01 bedient wurden. Und wir haben es wohl auch genau so gelöst.
Die Frage ist, was ist der Standard? Ist Denx nicht dem Standard angepasst? Oder haben wir das Cross-Entwicklungssystem nicht standard-mäßig generiert? Oder wo klemmt's sonst? Ein Kopieren der Dateien ist jedenfalls auf Dauer wohl nicht der richtige Ansatz. Da muss man noch mal denken oder mit dem Herrn Denk reden.
Peter fragt, ob eventuell ein passender Link helfen könnte, der ".../include/platforms" heisst und nach "...arch/ppc/platforms" zeigt? Damit würde man verlinken statt kopieren.
- Welche Werkzeuge zur Fehlerdiagnose sind notwendig? Braucht man z.B. wieder ein lokales Display wie bei MOPS?
- Server, also PPC-GuPs, heißen nach ihrem Standort. Das wäre in Zukunft z.B.
kg1cg77.acc.gsi.de.- Wie kann man den Namen beibehalten, wenn der PPC getauscht wird? Oder brauchen wir das nicht mehr?
- Was machen wir denn mit
#define ACT_DEV_IMPL GmDevicein den gm-usrs.cc, die für dieadd-default-usrs.ccusw. gebraucht werden? So isses nicht schön.
- Derzeit wird das update von Datum und Uhrzeit der SEs über den
lifeCtrlThreadinequinfo.ccerledigt (die Daten werden auslocaltime()gewonnen). Das muss längerfristig wohl noch anders gemacht werden.
- Geräteverwaltung: Was ist mit Adressen auf SEs, für die es keinen Eintrag im DB-File gibt:
- Ignorieren? (solange sie als NODEVICE im Zustand KNOWN sind,
ja, sonst s.nächster Punkt) - Können die trotzdem Alarme schicken? (dto.)
- Nomenklaturen erfinden und Objekte anlegen? (derzeit nicht geplant, wer soll damit was anfangen?)
- Ignorieren? (solange sie als NODEVICE im Zustand KNOWN sind,
- Die regelmäßige Konfigurationsprüfung des devman (
lifCtrlThread) macht für jedes device einchekSupStatus(). Möglicherweise muss man aber zwischencheckSupStatus()undupdateSupStatus()unterscheiden, wenn es sich um Geräte handelt, die nicht auf einer SE angeklemmt sind.updateSupStatus()meldet nur den aktuellen Zustand währendcheckSupStatus()ihn auch wirklich überprüfen müsste (was bei SE-Geräten auf der SE passiert).updateSupStatus()könnte beiVmeDevicesüberprüfen, ob alle Geräte der SE auch in der Datenbank eingetragen sind und gefundene Leichen entsorgen. (s.o.)
- Geräte-Gruppen (UK, 06. Feb. 08) Bisher werden alle Geräte eines Device-Managers (z.B. in VME-Rahmen) ist voneinander unabhängig betrachtet. Das sind sie aber in vielen Fällen nicht: Als Beispiel müssen für alle Integrator-Gitter an derselben Messelektronik die Integrationszeiten gemeinsam gesetzt werden. Dazu müssen die Gerätedaten aller zusammengehörigen Gitter mit angepasst werden, wenn ein Gitter dieser Gruppe verstellt wird.
Es sollte ein Verfahren implementiert werden, um die Verkopplungen der Geräte zu behandlen. Im einfachsten Fall kann dazu in einer Tabelle verzeichnet werden, welche Geräte zu einer Gruppe gehören, und die Geräte können sich aus dieser Tabelle die Nomenklaturen der beteiligten Geräte holen und über die Nomenklaturen z.B. die Gerätedaten abgleichen.
Ein konsequenterer Ansatz wäre, in Fällen wie der Integratorgitter die Gitterelektronik als eigene Geräte-Ebene einzuführen. die SE würde nur das Gerät "Gitterelektronik" behandeln. Die eigentlichen Profilgitter-Geräte existieren dann nur auf dem GµP und setzen auf dem Gerät "Gitterelektronik" auf, d.h. alle Zugriffe auf die Hardware laufen immer und nur über das Gerät "Gitterlektronik".
Accnomen
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding Foswiki? Send feedback