Release 13

Zeitrahmen: Mittwoch, 18. Februar 2009

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!

Die Icons bedeuten:
- der Punkt bedarf einer klärenden Diskussion.
- zum Punkt gibt es ergänzende Bemerkungen. Das Icon ist klickbar.
- der Punkt ist auf die nächste Release verschoben.
- der Punkt ist erledigt.

Klären

Nr.	Name	Prio	Projekt
1	LH	3	Wie bei Alarmen von der SE die richtige Nomenklatur zuordnen? Adressen sind nicht eindeutig, was tun bei STD?
2	LH	2	Welche ESR-Programme müssen gelinkt werden mit neuem Userface und wer tut's? Okay, bisher geplante Umstellungen liegen alle in der Verantwortung von AP.
3	Alle	3	Welche Features des Device-Accesses fehlen noch? Liste ins Wiki.
3.1	LH	3	Erster Punkt: Überwachung konnektierter Aufträge.
4	LH	3	Behandlung der Spezial-Nomenklaturen >> und ?? klären (siehe UKs Email vom 6.2.08). im PPC-WG-Meeting.
5	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.
6	SMa	2	Fehlerbehandlung in Klasse NsrvException ggfs. ersetzen durch AccDevException? Informationsweitergabe ueberdenken.
6.1	SMa	4	Log-Ausgaben des Nameservers ueber Demon abwickeln?
7	LH	2	USR-Absturz (z.B. NULL-Ptr) soll nicht zum Devman-Absturz führen.
8	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?

Bemerkungen

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

Nr.	Bemerkung
1	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!
4	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).
8	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.

Umfang

Nr.	Name	Prio	Tage	Projekt
1				Property-Beschreibung mit XML und Code-Generierung
2				Geräte-Software
2.1	Alle			Gerätemodelle umstellen. (Aktualisieren der Geräte-Software-Liste nicht vergessen.)
2.1.1	GSch	2		DTI
2.1.2	UK	2		HVDM
2.1.3	Kain	2		FG
2.1.4	GuRi	1		HFS
2.1.5	KHer	2		IS** auf Basis von STD
2.1.6	GuRi	2		PPOS
2.2	Alle			VME-Rahmen umstellen. MAC-Adressen der GuPs bei W.Schiebel angeben!
2.2.1	SMa	1		Einzige SE aus KE1CG6C_ nach KE1CS015 umziehen. Im Shutdown Ende Februar.
2.2.2	UK	1		KE3CG94_ wird KE3CG02, falls HVDM fertig wird.
2.2.3	KHer	1		KE3CG95_ wird KE3CG03.
2.3	Alle	1		Ausgiebige Test der umgestellten USRs mit realen Geräten.
2.4	LH	2		Planung der Umstellung der Rahmen K1XCG54_ und K1XCG57_. Im April-Shutdown.
3				Devman
3.1	SMa	1		Eintrag sekundäres EqMod in Nameservice (für Gerätemodell EC)
3.2	SMa	1		Eintrag in der Rechtedatei fuer SD korrigieren (LOCAL_SYSTEM), sobald neuer Nameserver laeuft.
3.3	LH	1		Erweitertes Exceptionhandling für Callbacks. Erweitertes Logging für CORBA-Exceptions.
4				Nameservice and Access Rights
5				Userface
5.1	GSch	1		Device-Objektreferenzen cachen.
5.2	KHoe	4		UfcServer auf dediziertem Rechner (asl3xx oder Fileserver) laufen lassen (nicht auf asl7xx).
5.3	GSch	5		waitResponse() implementieren
6				Versionsverwaltung, Releases, Produktionsbibliotheken
6.1	SMa	2		Makefile.infosnd und Makefile.nameservercmd für Release-Zwecke erstellen. Source nameservercmd.cc vom Projekt utiasl ins Projekt nameserver verschieben. Source infosnd.cc ins Projekt devman integrieren. (zur Zeit nur lokal bei Kain?)
6.2	KHoe	2		vmeconfig.py merkt sich Additional files.
6.3	LH	1		svntools.py für V09 anpassen. Nein, auf den Blades wird es eine viel einfachere Möglichkeit geben.
6.4	KHoe	3		Script mkgupdirs zum Anlegen der Directories eines neuen PPC-GuP.
6.7	LH	1		incmsg und libmsg release-unabhängig!
6.8	LH, KHoe	3		Wiki-Seite "Produktions-Releases in Betrieb nehmen" auf den Stand bringen.
7				ELDK
7.1	KHoe	1		Anpassen der SE-Software an M68k-Cross-Tools mit ELF- statt COFF-Format. In Zusammenarbeit mit LH und Kain.
7.1.1	KHoe	1		Installation und Test der Entwicklungsumgebung auf den neuen Blades (64 Bit).
7.1.2	KHoe	3		Umzug einiger Directories
7.2	Kain	1		Klären mit Denx/MicroSys: nicht funktionierender VME-Adresstest unter ELDK 4, Linux 2.6. In Zusammenarbeit mit KHoe.
8				Erweiterungen Device Access Interface
9				Subscription Service
10				Alarme
11				Allgemeines & Kleinigkeiten
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.

Bemerkungen

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

Nr.	Bemerkung
2.1.2	Eventuell ohne SE sondern mit dem HV-Controller direkt im VME-Rahmen. Möglicherweise können die HV-Controller auch direkt auf Netzwerkbetrieb (ohne Kontrollsystem) umgestellt werden.
2.4	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.
3.1	Zur Überprüfung der access-rights einer SE ist es nötig, von der SE zu wissen welches Gerätemodell darauf läuft (z.B. SD darf auf alle SEs mit DGX schreiben). Da müsste beim Eintragen des Gerätes (der SE) in den Nameservice noch der Gerätemodellname mitgeliefert werden. Davon weiss der devman aber nix und grundsätzlich soll er derartige Gerätespezifika auch nicht wissen müssen. Eine Möglichkeit wäre, die Anmeldung beim Nameservie in das device-implementation-interface zu verlagern, dann kann das Anmeldeverfahren z.B. für ein ec-device mit zusätzlichen Daten erfolgen.
5.2	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.1	Koennen jetzt schon zwei verschiedene Projekte in einem integriert sein???
6.2	Eigentlich muss man noch zwischen V08 und V09 unterscheiden. Z.B. bei MD und MX gibt's unter V08 keine zusätzlichen Dateien für die USRs einzutragen, unter V09 aber schon.
6.3	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.
6.8	Dabei Klaus' Email Skript zum Erstellen eines devman-Produktionsreleases vom 16.Jun.08 und eventuelle Änderungen bei der Versionierung berücksichtigen.

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	LH, Kain	3		Power schalten bei MX, FG: addPeriodical(n * 1sec) führt bei PPM-Geräten aber zu addPeriodical(n * Zykluszeit) und im Fehlerfall (Gerät schaltet nicht) zu zu langen Wartezeiten und zum Fehler USR-Timeout statt zu GM-Powerfail.
2.3	Kain	2		SWPZ-EQMs bringen SE zum Absturz, wenn man nur das Default-Alvarez-Timing einstellt.
2.4	GSch	2		DTI-EQMs: Wenn der Elektronik der Rahmenpuls fehlt, z.B. oft im Shutdown, dann rascheln die Geräte ziemlich mit Alarmen. Ein DevSpecAlarm wechselt ständig zwischen ok und Fehler und man hat schnell hunderte von Alarmfiles geschrieben.
3				Devman
3.1	Kain	1		Falsch zeigender deviceDataPtr nach einem Init der SE und der darauf folgenden Neusortierung der Geräte in der Geräteliste der SE. Siehe Peters Email PPC und Konfigurationsaenderungen vom 19.1.2009.
3.2	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.
3.3	LH, Kain	2		Siehe Email Absturz S09DT_ML vom 14. 1. 2009. Wahrscheinlich behoben mit dem des Bugs 3.4 hier drunter.
3.4	LH, Kain	2		Muss man das Benutzen der Multimap ConnectT nicht mit einer Semaphore schützen? Siehe Emails Semaphore für ConnectT in EcInfoPPC? vom 9. 2. 2009, die Abstürze (Tracebacks) des Devman dokumentieren.
3.5	KHoe	2		KP1CG01: Devman startet nicht automatisch nach Powerup. Wo muss das konfiguriert werden? Ist das sonst überall konfiguriert?
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 werden 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
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				vmeconfig verlangt nach *.xml, was ist mit ec? Siehe Email RE: USRs und make vom 13.2.09.
11.3				Wie kann man dem Nameserver eine Aenderung des Geraetemodells auf der SE mitteilen?
11.4				Es ist unklar, weshalb AccDevice, VmeDevice, etc von DeviceSupportInterface erben und gleichzeitig einen Pointer auf diese Klasse besitzen.
11.4	KHoe	3		Zu vmeconfig.py und "Additional files" merken muss man eigentlich zwischen V08 und V09 unterscheiden. Z.B. bei MD oder MX gibt's unter V08 keine zusätzlichen Dateien für die USRs einzutragen, unter V09 aber schon.
11.5	Kain	3		Gibts beim ecload einen Timeout (welchen genau?) auf dem GuP, wird dieser von ecload nicht gemeldet, sondern so getan, als wäre das Laden ohne Fehler beendet worden.