Devman, Nameserver und UfcServer
für Linux erstellen und freigeben

---

Verzeichnisstruktur

Unter $PROOT gibt es die Verzeichnisse

  build/<release>/<projects>
  include/
      asl/<release>
      msg
      vme/<release>
  lib/
      asl/<release>
      msg
  lib64/
      asl/<release>
      msg
  python/<release>

und unter $UROOT das (PPC-) Verzeichnis

  eldk/ppc_6xx/opt/acc/sys/devman/<release>

Für jede Release gibt es eigene Unterverzeichnisse. Ein Link namens current jeweils oberhalb der Verzeichnisse <release> zeigt auf die aktuelle Release. Message-Dateien sind unabhängig von einer Release.

In build/<release>/<project> liegen die Sources der aus Subversion ausgecheckten Projekte. Die von gendevacc generierten Dateien Makefile.clean, Makefile.copy, Makefile.nightly und nightly-conf.mk liegen in build/<release>. In build liegen die von gendevacc beim Generieren geschriebenen Log-Dateien <yyyy>-<mm>-<dd>.log.

In die Unterverzeichnisse include/asl/<release> und include/vme/<release> kommt der Inhalt der Projekte incasl bzw. incvme sowie die allgemeinen Header-Dateien aus den einzelnen Projekten.

In include/msg liegen alle Messageheader-Dateien, die von genmsg generiert wurden.

In lib/asl/<release> liegen alle Shared-Object-Bibliotheken, die Executables von Devman, Nameserver, UfcServer, Infosnd und Nameservercmd für die X86-32Bit-Plattform. Diese werden noch für die Operating-Programme benötigt, die auf Linux, auch auf den 64 Bit Blades, im 32-Bit-Format generiert werden.

In lib64/asl/<release> liegen alle Shared-Object-Bibliotheken, die Executables von Devman, Nameserver, UfcServer, Infosnd und Nameservercmd für die X86-64Bit-Plattform.

Die entsprechenden Shared-Object-Bibliotheken und Executables für die PPC-GuPs liegen von einer asl-Maschine aus gesehen in $UROOT/eldk/ppc_6xx/opt/acc/sys/devman/<release> bzw. von einem PPC aus gesehen in /opt/acc/sys/devman/<release>.

In python/<release> liegen die Python-Module, u.a. das Device-Access-Modul devacc.py.

---

Devman, Nameserver, UfcServer erstellen

Privat und lokal

In der Regel hat man eine lokale Verzeichnisstruktur wie folgt:

  ~/workspace/local/inc68
                    incasl
                    incvme
                    lib68
                    libasl
                    libasl64
                    libppc
                    python

Auf ~/workspace benötigt man die Dateien nightly-conf.mk, Makefile.version, Makefile.clean, Makefile.copy und Makefile.nightly, die man sich von ~/workspace/uti/mk kopiert.

In nightly-conf.mk muss die Variable TOP angepasst werden. Hat man obige Verzeichnisstruktur, dann definiert man

  export TOP=$(HOME)/workspace/local

PLATFORM gibt die Architektur an für die generiert werden soll, also x86_64, x86 oder ppc. Läßt man PLATFORM leer oder undefiniert, wird für beide Plattformen generiert.

Möchte man die PPC-Bibliothek auf einem PPC-Verzeichnis haben, muss man auch noch

  export libppc=/usr/local/acc/eldk/ppc_6xx/usr/local/scratch/${USER}

umdefinieren. Devman, Bibliotheken usw. für PPC liegen dann in einem benutzerspezifischen PPC-Verzeichnis, z.B. .../scratch/herlo.

Möchte man bestimmte Module nicht generieren, kann man sie aus TARGETS entfernen. Achtung, das macht nur Sinn für subscriptionservice, nameserver, python und ufcserver. Einzelne Projekte kann man mit

  make -f Makefile.nightly <project>

generieren.

Möchte man ein Test-Gerätemodell mitgenerieren, zur Zeit gibt es nur KGB, gibt man

  EQMODS = kgb

an.

Es macht Sinn, sich die Warnings des Compilers auch mal anzugucken, wenn alle Fehler beseitigt sind. Nicht selten bekommt man dadurch noch einmal Hinweise auf fragwürdigen Code. Dazu muss man in ppc.mk, x86.mk und x86_64.mk die Variable CXXFLAGS um die Option -Wall ergänzen.

ohne:  CXXFLAGS = -g -fpic -D...
mit:   CXXFLAGS = -g -fpic -Wall -D...

Wenn man mit dem Anpassen von nightly-conf.mk fertig ist, lautet die Reihenfolge der Aufrufe:

  make -f Makefile.version SYSRELEASE=15 SYSVERSION=00
  make -f Makefile.clean
  make -f Makefile.nightly

Das Makefile.copy darf nicht mehr nötig sein. Muss man es vor dem Aufruf von Makefile.nightly aufrufen, damit letzteres fehlerfrei funktioniert, hat man sehr wahrscheinlich eine Kreuzabhängigkeit zwischen zwei Projekten implementiert. Das darf nicht sein!

Wenn man an einzelnen Komponenten arbeitet, wird man natürlich in aller Regel das Makefile.clean weglassen. Bibliotheken und Devman landen dann in $libasl, $libasl64 bzw. $libppc.

Das Makefile.clean benutzt übrigens einen Schalter NODEPS=1, der verhindert, dass die .d-Dateien mit den Abhängigkeiten geladen werden (und im Zweifelsfall vorher erzeugt werden).

Makefile.nightly ruft auch jeweils ein Target checkwronglocation auf, das bei den Header-Dateien, die nach $incasl sollen, guckt, ob sie in incvme vorhanden sind und umgekehrt. Falls dies der Fall ist, wird eine Warnung

  ###Warning: <filename> seems to be in wrong location

ausgespuckt.

Will man (ziemlich) sicher gehen, dass auch ein späteres gendevacc mit den getaggten Projekten fehlerfrei funktionieren wird, empfiehlt sich folgendes Vorgehen:

  make -f Makefile.version SYSRELEASE=20 SYSVERSION=00
  rm -f $incasl/* $incvme/* $libasl64/* $libasl/* $libppc/* 
  make -f Makefile.clean
  make -f Makefile.nightly

Dabei müssen $incasl, $incvme, $libasl64, $libasl und $libppc auf die lokalen Verzeichnisse zeigen! Siehe die lokale Verzeichnisstruktur zu Beginn des Kapitels.

Allgemein mit gendevacc

Eine Release 15 komplett mit Bibliotheken, Devman, Nameserver und UfcServer generiert man mit

  gendevacc 15

Das Script überprüft, ob es die Release schon gibt, legt die notwendigen Verzeichnisse an, exportiert alle Quellen aus dem Subversion-Repository in das Verzeichnis build/<release> und generiert die Release. Natürlich müssen alle relevanten Projekte einen 'Tag' für die Release in Subversion haben.

Da gendevacc ziemlich viel Output macht, ist es eventuell sinnig, diesen in eine Datei umzuleiten. Mit Hilfe von tail kann man dann trotzdem weiterhin sehen, was passiert.

  gendevacc 15 1> rel15.log 2>&1
  tail -f rel15.log

gendevacc hat eine ganze Reihe von Optionen, die man sich am Besten mit

  gendevacc -H

detailliert anguckt.

Upgrades von Devman, Nameserver und UfcServer

In der Regel muss die Generierung einer Release die kompletten Device-Access-Quellen umfassen, da sich sehr leicht Inkompatibilitäten zwischen den Bibliotheken einschleichen können, wenn nur einzelne Bibliotheken nach-generiert und released werden.

Etwas entspannter ist das bei den drei Servern von Device Access, also Devman, Nameserver und UfcServer. Das sind Executables und sie stehen für sich selbst. Inkompatibel können sie nur werden, wenn sich die Schnittstelle zu den Anwendungen oder ihr definiertes Verhalten ändert.

Damit ist eine Nach-Generierung von Devman, Nameserver oder UfcServer für eine bereits bestehende Release möglich - aber trotzdem mit Vorsicht zu genießen!

Vorgehen am Beispiel von UfcServer für die Release 16gamma:

  protdevacc -a ug -s gamma 16          # Protection aufheben
  gendevacc -p ufcserver -s gamma 16    # Letztes Tag der Release 16 generieren
  protdevacc -s gamma 16                # Protection wieder setzen

Es ist kein relufcserver notwendig, weil der Link $PROOT/ufcserver/library ja schon auf das richtige Release-Verzeichnis zeigt. Der dortige Link ufcserver -> ufcserver.x86_64.16.04 wird von gendevacc gesetzt.

Das heißt aber, dass direkt nach dem Aufruf von gendevacc der neu generierte UfcServer der Produktions-Server ist! Das sollte man bedenken, wenn man ein Upgrade von UfcServer macht.

Das gleiche entsprechend gilt für den Nameserver und für Devman.

Besonders beim Devman muss man sich darüber im klaren sein, dass direkt nach dem Aufruf von gendevacc alle PPC-GuPs, die mit dieser Release arbeiten, den neu generierten Devman benutzen - nicht sofort, aber nach dem nächsten Restart! Weiterhin ist zu bedenken, dass der Devman und die USRs eng zusammenarbeiten, hier also eher Inkompatibilitäten auftreten können als bei Nameserver und UfcServer.

Messages

Das Projekt messages wird bei einem Lauf von gendevacc nicht mit-generiert, da es von Releases unabhängig ist. Notwendige Änderungen werden manuell mit dem Aufruf von make und den üblichen make-Targets all, clean, pythonmodules, copy, lib und release generiert. Mit

  make release

im Projekt messages erhält mein eine Komplett-Generierung und -Freigabe.

Achtung, Message-Tools benötigen den Message-Compiler msgc und die Bibliotheken libmsgintf, libcondmsg und libsysmsg, die von der Gruppe AP (R. Huhmann) auf /common/usr/bela/build/default/lib und /common/usr/bela/build/default/lib64 zur Verfügung gestellt werden.

---

Devman, Nameserver, UfcServer freigeben

protdevacc

Damit die von gendevacc generierten Dateien, aber auch die aus Subversion exportierten Quellen, nicht (versehentlich) überschrieben werden können, sollen sie mit

  protdevacc 15

anschließend geschützt werden. Auch protdevacc hat weitere Optionen, die man sich mit -H detailliert angucken kann.

Möchte man ein Projekt einer bereits bestehenden Release nach-releasen, also z.B. libos.so.18.00 durch libos.so.18.01 ergänzen (siehe Option -p von gendevacc), muss der Schutz zunächst aufgehoben werden. Nach dem Generieren nicht vergessen, die Dateien wieder zu schützen! Also

  protdevacc -a ug 18
  gendevacc -p os 18
  protdevacc 18

Es empfiehlt sich, Schreibrechte für User (u) und Group (g) zu vergeben, sonst können Dateien, die anderen Usern gehören, nicht geschrieben werden.

reldevacc

Macht die angegebene Release zur aktuellen (oder current) Release. Alle current Links (siehe Verzeichnisse) werden auf diese Release gesetzt. Detaillierte Hilfe gibt's auch hier mit -H.

reldevman

Den Devman für einen bestimmten PPC-GuP releasen kann man mit

  reldevman kp1cg02 15

Gibt man keine Release an, wird die aktuelle Release genommen.

reldevman funktioniert im Moment nur für PPC-GuPs.

relnameserver

Den Nameserver releasen kann man mit

  relnameserver 15

Gibt man keine Release an, wird die aktuelle Release genommen.

relufcserver

Den UfcServer releasen kann man mit

  relufcserver 15

Gibt man keine Release an, wird die aktuelle Release genommen.

---

Log-Dateien

Die Gen- und Rel-Tools loggen ihre Tätigkeiten in einer Log-Datei <yyyy>-<mm>-<dd>.log. Dort kann man nachlesen, wer wann was getan hat.

Die Log-Dateien liegen in der Regel auf $PROOT/build.

Die von reldevman geschriebene Log-Datei liegt auf [$UROOT/eldk/]/opt/acc/cpu.

---

Infosnd

Im Unterverzeichnis infosnd des Projektes devman finden sich die Quellen sowie die Makefiles fuer das Kommandozeilentool infosnd. Mit den Aufrufen

  cd ~/workspace/devman/infosnd
  make -f Makefile.infosnd
  make -f Makefile.infosnd release

werden die ausfuehrbare Datei erzeugt und released. Fuer eine neue Version muessen ggfs. die Dateien x86_64.mk, x86.mk und ppc.mk angepasst werden.

---

Nameservercmd

Im Unterverzeichnis nameservercmd des Projektes nameserver finden sich die Quellen sowie die Makefiles fuer das Kommandozeilentool nameservercmd. Mit den Aufrufen

  cd ~/workspace/nameserver/nameservercmd
  make -f Makefile.nameservercmd
  make -f Makefile.nameservercmd release

---

Nsrvrem

Im Unterverzeichnis nsrvrem des Projektes nameserver finden sich die Quellen sowie die Makefiles fuer das Kommandozeilentool nsrvrem. Mit den Aufrufen

  cd ~/workspace/nameserver/nsrvrem
  make -f Makefile.nsrvrem
  make -f Makefile.nsrvrem release

---

Access-Unittest

Im Verzeichnis access_unittest finden sich die Quellen sowie die Makefiles fuer das Kommandozeilentool access_unittest. Mit den Aufrufen

  cd ~/workspace/access_unittest
  make -f Makefile.access_unittest
  make -f Makefile.access_unittest release

---

Messages für VMS

Falls es Änderungen in den Messagefiles gab, z.B. oda-msg.msg, diese nach VMS kopieren und dort generieren, damit auch die Anwendungen, z.B. NODAL, die neuesten Messages kennen.

  ~/workspace/device/oda-msg.msg  ->  AXP704::SIS$ROOT:[SYSVME.DEVMAN]ODA$MSG.MSG

  AXP704> cd sis$root:[sysvme.devman]
  AXP704> @oda$msg