Release 12

Zeitrahmen: 19. November 2008

Shutdown: 21. Oktober bis 30. November 2008. Anschließend nur UNILAC-Betrieb vom 10. bis 17. Dezember.

Prioritäten:
1 - Muss mit der aktuellen Release fertig werden, da dringend benötigt
2 - Soll mit der aktuellen Release fertig werden, aber (noch) nicht dringend
3 - Wünschenswert, da spürbare Erleichterung für Betrieb / Arbeit der Gruppe
4 - Ganz nett, nice to have
5 - Beruhigt irgendwen irgendwie, stört zumindest nicht
6 - Stört / behindert, besser gar nicht angehen

Beim Implementieren bitte wieder die Merkliste und die Windows-Merkliste beachten!

Ein bedeutet, dass der Punkt einer klärenden Diskussion bedarf.
Auf ergänzende Bemerkung wird mit hingewiesen. Das Icon ist klickbar.
Erledigte Punkte sind mit gekennzeichnet.

Klären

Nr.	Name	Prio	Projekt
1	LH	1	Versionsnummern-Vergabe und Release-Strategie überdenken und beschließen.
2	KHoe	1	Automatische Konvertierung V08/V09-Daten in AccDevice. Nochmal im PPC-WG-Meeting diskutieren.
3	UK	1	Begrifflichkeiten zu 'Gerätemodell' klären: Was bezeichnet Properties, was SW-Module (SE und GµP) ?
3.1	LH	1	Wie können bzw. sollen Gerätemodell-Varianten unter V09 implementiert werden? im PPC-WG-Meeting.
3.2	NN	3	Wie kann so was wie Gerätemodell STD behandelt werden?
3.3	NN	3	Wie bei Alarmen von der SE (kennt zunächst nur Adressen) die richtige Nomenklatur zuordnen? Adressen nicht eindeutig, was tun bei STD?
4	Alle	3	Liste der zukünftigen Standard-Properties nochmal mit AP und Kain diskutieren. im PPC-Meeting.
5	Alle	3	Welche Features des Device-Accesses fehlen noch? Liste ins Wiki.
5.1	LH	3	Erster Punkt: Überwachung konnektierter Aufträge.
6	LH	3	Behandlung der Spezial-Nomenklaturen >> und ?? klären (siehe UKs Email vom 6.2.08). im PPC-WG-Meeting.
7	NN	3	Änderung einer Nomenklatur im DevMan (TR1KY1 nach TR1KYA). Wie Nomenklatur in SE anpassen?
8	LH	3	Für mutex zwischen GuP und SE wird ein echtes testAndSet() (read-modify-write via VME-Bus) benötigt! Klären, wie das geht. Siehe auch meine Email Test-and-set unter PowerPC von LH vom 8. Aug. 08.
9	SMa	3	Fehlerbehandlung in Klasse NsrvException ggfs. ersetzen durch AccDevException? Informationsweitergabe ueberdenken.
9.1	SMa	3	Log-Ausgaben des Nameservers ueber Demon abwickeln?
10	Kain	2	Was machen wir mit dem nicht funktionierenden VME-Adresstest auf der CPU87?
11	KHoe	2	Wie können die Entwicklungsumgebungen für ELDK 3 mit Linux 2.4 einerseits und ELDK 4 mit Linux 2.6 andererseits parallel gehalten und einfach umschaltbar gemacht werden?
12	KHoe	3	Handhabung des Java-Codes (Device-Adapter): Wo in Subversion die Quellen unterbringen, wie .jars bauen, wie für User bereitstellen (welche directories), ...
13	LH, KHoe	2	Verwaltung der Originale von /etc/rc.d/init.d/devman, /etc/sysconfig/devman, /home/vme/interrupt/ec-irpts-load.sh, ic-irpts.c usw. beschließen.
14	KHer	5	Wie können sich der Devman und die Konfigurations-Applikation der SD-Gruppe den PMAC-Treiber teilen? Ist erstmal verschoben worden.
15	KHer, KHoe	3	Integration der mBox/microIOC-Entwicklung in die Devman-Entwicklungsumgebung.
16	UK	4	Das für Doxygen in den Quellen codierte Python Reference Manual Doku tut nicht mit Doxygen (kein Output). Warum?
17	LH	2	Soll das neue ec-irpts.o für alle Rahmen genommen werden? Ja!
18	LH	1	Wo sollen sich für eine Periodische-Konnektierung Usr-spezifische Gerätedaten gemerkt werden? In den Parametern. Siehe LHs Email Konnektierungsart Monitor - quick and dirty vom 1.Okt.08.

Bemerkungen

Ergänzende Bemerkungen, Hinweise usw. zu obiger Liste "Klären".

Nr.	Bemerkung
1	Zum Beispiel würden unter $PROOT/asl/lib/v01 nur Produktions-Shared-Objects liegen, die explizit freigegeben wurden. Programme im täglichen Betrieb würden diese Shared-Objects benutzen und hätten keine (Kompatibilitäts-) Probleme mit upgedateten Shared-Objects auf $DROOT/lib/asl/v01. Aber auch die ...opt/acc/cpu, .../eqp und .../sys Directories bedenken.
3	Derzeit wird lax von "Gerätemodell" oder auch "Gerätetyp" geredet. Mal wird der Satz der Properties, mit ihren Eigenschaften, damit bezeichnet, mal die Gerätesoftware, die sie implementieren, mal die zugehörige SE-Software. Dazwischen besteht schon lange keine eindeutige Beziehung mehr: Die Gerätesoftware-USRs MX (dasselbe Modul mx-usrs.c) implementieren die Properties sowohl für das Gerätemodell MX als auch für das Gerätemodell MX0 (Feldmessung). Die Gerätesoftware für die Gerätemodelle ISAU, ISMO und andere arbeiten mit USRs des Gerätemodells STD und vor allem mit den std-eqms auf der SE-Seite. Eine klare Trennung der Begrifflichkeiten (Property-Satz, USR SW-Modul) und die saubere Kennzeichnung, was wozu gehört (welche Properties gehören zu welchem Property-Satz, welche Property-Sätze (MX und MX0) werden durch welches USR-Modul implementiert, und welche Property-Sätze/USR-Sätze arbeiten mirt welcher SE-Software zusammen?) kann man wahrscheinlich die folgenden Aufgaben durchsichtiger lösen.
3.1	Beispiel: Gerätemodelle MX und MX0 bzw. MD und MD0. Unter V08 werden für die Degaussingvarianten einfach nicht alle Properties (in createMap()) angemeldet. Unter V09 muss man das irgendwie anders machen. Möglicherweise wird dann auch die XML-Generierung erweitert werden müssen. Bedenken muss man, dass ein Gerät, das in der Datenbank (*.dbd) mit dem Gerätemodell MX0 geführt ist, bisher ein eigenes entsprechendes shared object mx0.so benötigt. Kann man es schaffen (siehe Punkt 3), dass ein shared object beide Property-Sätze MX und MX0 implementiert?
3.2	Die auf Basis von STD erstellten Gerätemodelle müssen auch bedacht werden. Bei genauerer Betrachtung zeichnen sich STD basierte USRs gerade dadurch aus, dass die Umsetzung der Daten einer Property auf gerätespezifische Größen mit Hilfe von vorgefertigten Verfahren durchgeführt wird. Es wird eine Funktion benutzt, die über Parameter gesteuert den Sollwert umrechnet und per Command an die SE schickt. Die benötigten Umrechnungsfaktoren werden den Gerätekonstanten entnommen. Das könnte man wahrscheinlich sogar über einen Codegenerator erledigen lassen.
3.3	Alarme: Bei Alarmen von SEs wird bisher über die LogDevAdr die richtige Nomenklatur des Gerätes ermittelt. Das geht jetzt aber nicht mehr so, weil die LogDevAdr. jetzt nur noch pro Gerätemodell innerhalb eines VME-Rahmens eindeutig sein muss. Speziell bei Gerätemodell-Varianten (auf USR-Ebene) hat man Probleme über LogDevAdr. + Gerätemodell-Name an die Nomenklatur zu kommen, denn die Nomenklatur gehört oft zu einem anderen Gerätemodell als die Software auf der SE angibt. Wie kann man trotzdem diese Zuordnung eindeutig und passabel handhabbar herstellen? (Extra Eintrag im DBS-file?). Siehe auch Punkt 3.2 (Gerätemodell-Varianten). Speziell bei STD-Geräten ist diese rückwärtige Ermittlung manchmal nicht möglich, weil da oft mehrere Geräte auf derselben LogDevAdr aufsetzen. Die SE kennt mittlerweile selbst die Gerätenomenklaturen, könnte sie also direkt verwenden statt der Adresse. Achtung, Änderung wäre eine Systemsoftware-Änderung! Haben wir die aber nicht eh mit der neuen Timestamp? Die SE kennt ihre eigene Nomenklatur nicht. Die sollte ihr mitgeteilt werden. Achtung, auch das ist wahrscheinlich eine Systemsoftware-Änderung!
6	Bisherige Nomenklaturen '>>', '??': Es soll erkennbar sein, dass es Adressen am MIL-Bus gibt, die dort nicht vorgesehen sind (keine Nomenklatur vorhanden). Dabei unterscheiden von Adressen, denen kein nutzbares Gerät entspricht, die aber da sein müssen, (oft bei SD-Geräten, die einen ganzen Adressraum belegen).
10	Da die Frage nach wie vor nicht geklärt ist, wird auch Release 12 noch mit Linux 2.4 laufen!
11	Möglicherweise müssen wir einen fließenden Übergang von Linux 2.4 nach 2.6 machen. Dann muss man einfach zwischen den Entwicklungsumgebungen umschalten können. Auf jeden Fall muss es eine einfache Rückfallmöglichkeit geben, wenn sich herausstellt, dass es unter Linux 2.6 Probleme gibt, die nicht schnell zu beheben sind.
17	Dieses Modul ist für die Wiener-Rahmen mit maximal 16 SEs erweitert. Es liegt (vom PPC aus gesehen) auf /home/vme/interrupt/new. Das etc/rc.d/init.d/devman von KP1CG03 ist darauf temporär angepasst! Siehe auch LHs Email KG1CG01 zum Test des Wiener-VME-Rahmens vom 7.Aug.08.
18	Bei dem Gerätemodell DS werden Gerätedaten pro Konnektierung im dazugehörigen Netzwerkpaket gespeichert. Wird die Usr aufgerufen befindet sich bei den Usr-Parametern ein Pointer auf die gespeicherten Gerätedaten. Diese Vorgehensweise ist im neuen System nicht mehr möglich.

Umfang

Nr.	Name	Prio	Tage	Projekt
1				Property-Beschreibung mit XML und Code-Generierung
2				Geräte-Software
2.1	Kain	1		ECM auf 1970-Timestamp-Format umstellen.
2.2	Kain	1		ECM und 1970-Timestamp noch mal überdenken. U.a., was verschickten die PZs?
2.3.1	Alle	1		Alle Produktions-PPCs auf Release 12 umstellen. Das sind K4XCG01, KE1CG01, KE3CG01, KG1CG01, KG1CG02, KTRCG01 und KUECG01.
2.3.2	Alle	1		Anpassung Display-EQMs an neues 1970-Timestamp-Format.
2.3.3	KHer	1		microIOC (M-Box), KE1CI01, auf Release 12 umstellen. Eventuell muss auch die Anwendung an das neue Device Access angepasst werden.
2.4	Kain	2		SWPZ-USRs testen (ist auf XML generierte Adapter umgestellt)
2.5	Alle			Gerätemodelle umstellen. (Aktualisieren der Geräte-Software-Liste nicht vergessen)
2.5.1	SMa	2		Gerätemodell DPX umstellen.
2.5.1.1	SMa	2		Gerätemodell DPB umstellen.
2.5.2	SMa	2		Gerätemodell DTX umstellen: Mutex statt testAndSet() benutzen.
2.5.3	SMa	2		Gerätemodell DX umstellen.
2.5.4	KHer	2		Gerätemodell DCI umstellen
2.5.5	SMa	1		Ausgiebeige Test der umgestellten USRs mit realen (SIS-) Geräten ab dem Oktober-Shutdown.
2.5.6	LH	3		Rahmen K1XCG54_ und K1XCG57_?
2.5.7	SMa	3		Rahmen KE1CG6B_ mit DX und TG auf PPC-GuP umstellen.
2.5.8	SMa	2		Gerätemodell DC umstellen. Noch testen.
2.5.9	SMa	2		Gerätemodell TG umstellen. Noch testen.
2.5.10	SMa	2		Gerätemodell TGX umstellen. Noch testen.
2.5.11	KHer	2		Gerätemodell DS umstellen.
2.8	Kain	3		Im Zuge der Einführung der 1970-Timestamp die Alignment-Anpassungen des SE-Therapiespeichers an V08 wieder rausnehmen.
3				Devman
3.1	KHer	1		Wenn bei updateDevConst Fehler bei einem von mehreren Geräten: update restlicher Geräte sicherstellen
3.2	KHoe	1		Die parallele Nutzung lebendiger Daten (z.B. devMap) durch Verwendung geeigneter Maßnahmen (Mutex?) absichern
3.3	LH	2		Das neue ec-irpts.o (max. 16 SEs) für alle Rahmen nehmen.
4				Nameservice and Access Rights
4.2	NN	3		In Makefile.nightly bzw. nightly-conf.mk das Tool nameservercmd generieren und releasen (in utiasl).
5				Userface
5.1	GSch	1		Userface auf AXP auf QIO umstellen.
5.2	GSch	1		UfcServer Release 12 als Produktions-Server.
5.3	GSch	2		UfcServer: SubscriptionService einbinden.
5.4	KHoe	3		UfcServer auf dediziertem Rechner (asl3xx oder Fileserver) laufen lassen (nicht auf asl7xx).
5.5	GSch	4		waitResponse() implementieren
5.6	GSch	2		Userface für devman-Geräte in allgemeine Kontrollsystem-Library (SISLIB.OLB) aufnehmen
6				Versionsverwaltung, Releases, Produktionsbibliotheken
6.1	KHoe	3		svntools.py für V09 anpassen.
6.2	LH	2		PYTHON_PATH in den Scripts eqpact, sysasl usw. definieren.
7				ELDK
7.1	Kain	3		Testweise Umstellung eines Produktionsrahmens im UM-Zweig auf ELDK 4 mit Kernel 2.6 und GSW.
7.2	KHoe	3		Upgrade asl-Cluster auf Blade-Rechner mit neuer RedHat-Version
7.2.1	KHoe	3		Frühzeitig Test-Blade zur Verfügung stellen.
7.2.2	KHoe	3		Installation und Test der Entwicklungsumgebung (2.4 oder 2.6 oder beide?).
7.2.3	KHoe	3		Umzug einiger Directories
8				Erweiterungen Device Access Interface
8.1	KHoe	3		Automatische Konvertierung V08/V09-Daten in Accdevice
8.2	UK, KHoe	3		Einbauen (Makefile.nightly etc.), dass für Python devacc die Verzeichnisse und Dateien für Zugriffe auf beide Interfaces (CorbaInterface und CorbaInterface01) generiert werden (siehe hier).
8.2.1	KHoe, UK	3		In diesem Zusammenhang devacc objektorientierter implementieren.
8.3	UK	2		Python-Modul devacc.py, AccStamp: String-Repräsentation um Datum erweitern
9				Subscription Service
10				Alarme
10.1	LH	1		Anpassung Alarme an geänderte Timestamps.
10.1.1	LH	1		Projekt alarm anpassen.
10.1.2	LH	1		MAX unter VMS.
11				Allgemeines & Kleinigkeiten
11.1	UK	2		dbsgen soll Output *.dbs auf die passende CPU-Directory legen. Evtl. nur als Option.
11.2	KHoe	3		Python soll den Library-Path zum import von devacc automatisch kennen, ohne dass man den LD_LIBRARY_PATH explizit setzen muss.
11.3	NN	3		Alle GuPs auf 19200 Baud umstellen, siehe Boot-Konfiguration der PowerPC-Boards
11.4	LH	2		Kochbuch: Ersatz von tm_wkafter() duch usleep()

Bemerkungen

Ergänzende Bemerkungen, Hinweise usw. zu obiger Liste "Umfang".

Nr.	Bemerkung
2.5.1.1	DPB wird nun als eigenes Geraetemodell umgesetzt.
2.5.2	testAndSet() wird anscheinend nur in DTX verwendet, und nur auf USR-Seite.
2.5.5	Das SIS geht dann 2008 nicht mehr in Betrieb, man hat also ausgiebig Zeit zum Testen.
2.5.6	Diese Rahmen sind oft stark mit viele Konnektierungen belastet. Aus diesem Grund sind sie dann nur noch sehr schlecht zu erreichen oder stürzen gar ganz ab. Das Operating hat also ein Interesse, dass die Situation bald verbessert wird.
2.5.7	Was ist mit den Geräten S01DP1P, S04DP2P und S07DP3P im Rahmen KE1CG6D_? Die laufen auch mit der Geräte-Software DX. Was ist mit dem Timing-Generator S00ZG in KE1CS6B1? Wird der noch benötigt? Wenn ja, muss er auch umgestellt werden.
5.4	Was spricht eigentlich dagegen, auf jedem asl3xx und asl7xx einen UfcServer laufen zu lassen? Auf verschiedenen AXP3xx- und AXP7xx-Rechnern könnte man dann unterschiedliche Listen mit anzusprechenden Servern haben, um die Last schön zu verteilen.
6.2	Wo müssen die Dateien *.pyc zu liegen kommen? Zur Zeit findet man sie sowohl unter /usr/local/acc/python/bel als auch unter $utivme. Das muss bereinigt werden.
7.2	Seit langem vorgesehen: Neue Rechner im asl-cluster (blades), auf denen eine aktuellere Linux-Version laufen soll. Entwicklungsumgebung entsprechend anpassen.

Bugs

Nr.	Name	Prio	Tage	Beschreibung
1				Property-Beschreibung mit XML und Code-Generierung
2				Geräte-Software
2.1	NN			Default-Property EQMERROR liefert falsche Werte.
2.2	Kain			ECM 09.10, lokales Display: Ruft man den Menüpunkt F auf und unterbricht die Ausgabe mit X, dann kann man mit einem erneuten Aufruf von F keine EQMs mehr sehen.
2.3	Kain			ECM 09.10, lokales Display: Mit Menüpunkt 2 das EQM 255 aufzurufen und beim Param-Count z.B. y statt 0 (Null) angeben. Damit hängt sich das Display auf.
3				Devman
3.1	LH	2		Ein Client (der UfcServer) stürzt ab, wenn ein RequestThread genau in dem Moment antwortet (via readResponse()), wenn das Callback-Objekt des Clients bereits gelöscht ist, das CorbaCallback-Objekt aber das des Clients noch aufrufen will (z.B. via _userCallback->response()). Beim Löschen des Client-Callbacks muss also das CorbaCallback angewiesen werden, diesen Pointer zu löschen. Außerdem muss er immer auf ungleich Null überprüft werden! Muss auch das cancelRequest() implementiert werden? Das kann so jetzt beim ufcserver nicht mehr pasieren, da jetzt beim Schliessen das Kanals ein cancelRequest() geschickt und auf eine Bestätigung gewartet wird. (GSch).
3.2	KHer	2		Schaltet man den PPC-GuP bzw. den VME-Rahmen aus, während der Devman noch läuft, dann hat dieser keine Chance mehr, sein Lockfile zu löschen. Entsprechend startet er auch nicht mehr nach dem Einschalten, weil er das Lockfile noch vorfindet.
3.1	Kain	2		TL2MU1 (MX, IFK=205) auf KG1CS023 ist online, KG1CS022 hat keine Geräte. MIL-Bus auf KG1CS022 umstöpseln und Init KG1CS022. TL1MU1 (MD, IFK=205) ist mit Menüpunkt 'C' auf der SE zu sehen und online. TL2MU1 auf KG1CS023 ist offline. Lesen von Status via Python: TL1MU1 > =XSR-E-UNKNOWN, TL2MU1 >                          =XSR-E-UNKNOWN. Erst ein Restart des Devman scheint zu helfen. Alles unter Release 9.
4				Nameservice and Access Rights
5				Userface
5.1	NN	2		Es gibt noch ufcserver Abstürze: 1.-segmentation fault bei Zugriff auf die exitMethode des ufcservers durch DeviceAccess provoziert duch 2 Fenster mit vmeterminal auf der gleichen SE. Wird das erste Fenster mit ctrl-y gestopt, macht der ufcserver des zweiten besagte Probleme. 2.- subscriptionService: nur die erste Konnektierung läuft richtig, bei der zweiten gibts einen ufcServer Absturz sobald das erste Mal die user-response Methode aufgerufen weden soll.
5.2	GSCH	2		ctrl-y bei VMS-Programmen führt zu Hängern. Exit-Händler wartet auf Antworten von cancelRequest und disconnect, die nicht mehr kommen
6				Versionsverwaltung, Releases, Produktionsbibliotheken
7				ELDK
8				Erweiterungen Device Access Interface
9				Subscription Service
10				Alarme
10.1	LH	1		Einen Alarm schicken via send-alarm -> MAX -> CAPTST tut nicht. Der Alarm wird nicht angezeigt. Allerdings kann man ihn im Logfile *.ALR finden! Der geht via send-alarm -> MAX -> CAPLOG. Überall, wo ein CAP auf einer AXP läuft, muss auch ein MAX laufen!
10.2	LH	1		Die Timestamp von Alarmen, via send-alarm -> MAX -> CAPLOG geschickt, geht im Logfile *.ALR um 2 Stunden nach. Das ist ein VMS/Linux-MEZ/UTC-Zeitproblem.
11				Allgemeines & Kleinigkeiten
11.1	KHoe	2		Die PPC-Boards, zumindest KP1CG01 (auch KE3CG01?), stellen sich mal auf full duplex, mal auf half duplex ein, wenn der Port am Switch auf auto steht. PPC-Boards müssen immer auf full duplex stehen! Kontakt mit MicroSys bzw. Denx aufnehmen.
11.2	Alle	3		Überprüfen, ob alle Quellen die richtige Endung haben. Besonders beim Nameservice und bei den Access-Rights noch mal gucken. Vereinbart ist, dass Quellen, die C++-Elemente enthalten, unter Linux mit .hh bzw. .cc enden. Nur Quellen, die explizit keine C++-Elemente enthalten sollen oder können, enden mit .h bzw. .c.