You are here: Foswiki>Frontend Web>EmbeddedLinux>EmbeddedApplications (06 Sep 2013, ChristophHandel)Edit Attach

Applikationen auf Embedded Sytemen

Die urspruengliche Annahme ist, dass es eine ueberschaubare Anzahl von Architekturen (i686, ppc), Hardwaretypen (scu, cpu87, microioc) und applikationen (devman, fesa) gibt.

Fuer jede Architektur sollte moeglichst eine generische Ramdisk existieren. In der Ramdisk ist ein Betriebssystem welches das Sytem ins Netzwerk bringt. Applikationen werden dann vom NFS nachgeladen.

NFSinit

Es wird versucht moeglichst viele Systeme mit einer Ramdisk zusammenzufassen. Derzeit waeren dies drei. alle SCU (i686 realtime), alle microioc (i686), alle cpu87 (ppc). Die ramdisk kuemmert sich um Netzwerk, syslog, etc. Keine Applikation ist in der Ramdisk.

Fuer jede Applikation gibt es einen per NFS erreichbaren Applikationsordner (/common/export/$APP/). In diesem Verzeichnis existiert ein applikations-init script (/common/export/$APP/$APP.sh). Innerhalb einer Applikation gibt es Architektur Ordner (/common/export/$APP/$ARCH/). Jeder host besitzt ein spezifisches Verzeichnis (/common/export/$APP/local/$HOSTNAME/) fuer seien konfigurationsdaten (/common/export/$APP/local/$HOSTNAME/conf/) und spezifischen init scripte (/common/export/$APP/local/$HOSTNAME/init/)

Fuer jedes System gibt es einen per NFS erreichbaren systemspezifischen init ordner (/common/export/system/$HOSTNAME/init/).

Der gesamte Bootvorgang

  • ramdisk, sytem ins netz, initscripte der ramdisk ausfuehren
  • mount fsl00c:/common/export/nfsinit /opt/nfsinit
  • wenn /opt/nfsinit/$HOSTNAME/ existiert alle scripte darin ausfuehren. Diese sind im normalfall symlinks ../global/
  • z.B. 20_gpib -> ../global/gpib (-> fsl00c:/common/export/nfsinit/global/gpib)
    • mount fsl00c:/common/export/gpib /opt/gpib
    • exec /opt/gpib/gpib.sh
      • modprobe /opt/gpib/$ARCH/$KERNELVERSION/gpib_common.ko
      • ...
      • cp /opt/gpib/local/gpib.conf /etc/gpib.conf
      • cp /opt/gpib/$ARCH/gbip_conf /sbin
      • exec /sbin/gpib_conf
      • umount /opt/gpib
  • z.B. 50_devacc -> ../global/devacc (-> fsl00c:/common/export/nfsinit/global/devacc)
    • mount fsl00c:/common/export/devacc /opt/devacc
    • exec /opt/devacc/devacc.sh
      • umgebungsvariablen setzen
      • ...
      • devacc ausfuehren

  • Negativ
    • nicht trivial nachzuvollziehen was in welcher reihenfolge ausgefuehrt wird
    • alle systeme sehen alle initscripte
    • robuste shell-scripte schreiben!
    • rechteverwaltung auf dem fsl00c nicht trivial
  • Positiv
    • flexibel

Idee, beim ersten starten die init scripte in die ramdisk kopieren und danach mount /nfs/system aufgeben.

Konzept Standalone

Jedes System erhaelt eine eigene Ramdisk. In dieser Ramdisk sind saemtliche Applikationen mit ihren Konfigurationsdateien und Startscripten.

  • Negativ
    • fuer jede permanente Aenderung an den Konfigurationsdateien muss eine neue Ramdisk erzeugt werden
    • ggf unterschiedliche Applikations-versionen auf verschiedenen Systemen (Scriptgesteuerte generierung der Ramdisk und zentrales Repository unterbindet dies)
  • Positiv
    • Klare Struktur auf dem System
    • Systeme sind autark (einmalig PXE zum booten)
    • Unabhaengige Aenderungen an jedem System

Konzept Mischung

Man kann sich beliebe Zwischenkonzepte vorstellen. z.B. alle Hardware Initialisierung erfolgt in der Ramdisk (was dann bei den Microioc eine ramdisk mit gpib und eine ohne bedeutet) und nur "generische" Applikationen werden nachgeladen.

Edit  | Attach | Print version | History: r2 < r1 | Backlinks | View wiki text | Edit wiki text | More topic actions
Topic revision: r2 - 06 Sep 2013, ChristophHandel
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback