[ag-automation] neuer Mitleser

[Wolfgang Denk]

Hallo Herr Wild,

in message <4434EBED.3050505 at osadl.org> you wrote:
>
> Im Wesentlichen geht es um die Standardisierten Schnittstellen. In dem
> Fall des Echtzeitbetriebssystem eben um POSIX. Aber Schnittstellen sind
> eben nicht von alleine lauffähig. Uns als Anwender geht es darum
> Applikationen von Zulieferanten zu bekommen, die auf einem
> Betriebssystem, welches diesen Schnittstellen genügt, auch sofort

Dem stimmeich uneingeschränkt zu. Das ist das erklärte Ziel, und  das
oll es bleiben.

> laufen. Unsere Erfahrungen mit RTAI und dem dortigen Versionschaos waren
> ernüchternd. Desweiteren war die Funktionalität der APIs für unseren
> Anwendungsfall mehr als schlecht.

Auch hier haben Sie völlig recht.

> Ergebnis war, dass wir als Homag auf keinen Fall einen Dual Kernel
> Ansatz akzeptieren, weil wir dadurch die Vorteile am Linux Mainstream
> partizipieren zu können, nicht gewährleistet sehen.

Sie können  Xenomai  nicht  mit  RTAI  vergleichen.  Werder  von  der
Implementierung, noch von der Qualität oder den Interfaces.

Und von einer unbefriedigenden Implementierung sollte man m. E.  auch
nicht auf ganze Konzeptklassen schließen.

Aber das ist eigentlich off topic - Sie als *Anwender* soll es ja ge-
rade NICHT interessieren, was für ein Motor unter  der  Haube  läuft.
Wenn  er  die vereinbarten Schnittstellen bietet und seine Arbeit zu-
verlässig tut, kann es Ihnen letztlich egal sein, welche  Technologie
verwendet wird. das ist *unser* Thema als Softwareentwickler.

> Wir wollen Schnittstellen festlegen. Aber wir wollen auch eine
> Referenzimplementierung, die diese Schnittstellen befriedigt und
> funktioniert. Und wir wollen dass die Anwender einen leichten Einstieg

Ja. Und wir wollen sicherstellen, daß es offene  Schnittstellen  sind
und  eine  auf Xenomai basierte Referenzimplementierung bereistellen,
die diese Schnittstellen befriedigt und funktioniert.

> haben und schnell zum Erfolg kommen. Wenn ich die Fragmentierung der
> Echtzeit-Communities sehe so ist es für mich als Entscheider sehr
> kritisch, mich auf einen kleine Community zu verlassen, die neben der
> Echtzeit auch noch User Space Libraries "from scratch" implementieren
> und pflegen muß.

Das ist genau ein Punkt, warum wir uns für Xenomai entschieden haben.
Ich habe dabei z. B. API's wie RTDM, die Skins für VxWorks usw.,  den
RT-Simulator  usw.  im Auge. Aber noch einmal: das ist eigentlich off
topic hier. Ich will niemand von den Vorteilen der einen oder anderen
Lösung überzeugen. Ich will nur, daß wir - wie in der  Free  Software
Community  relativ  häufig  anzutreffen  -  das  gleiche  Problem mit
verschiedenen Implementierungen angehen können. Das schedet  niemand,
kann aber dem einen oder anderen nützlich sein.

Wenn Homag aus welchen Gründen auch immer eine der  Implementierungen
nicht mag, ist das völlig ok.


> Sicher sind alternative Implementierungen möglich. Aber ich denke gerade
> für Entscheider in der Automatisierungstechnik ist es von höchster
> Wichtigkeit, dass zumindest eine Implementierung verlässlich
> funktioniert und man als Hersteller auf diese verweisen kann. Ansonsten
> werden wir wohl als OSADL mit unserer Klientel nicht ernst genommen.

Dem stimme ich wieder voll und ganz zu. Wir  werden  uns  dabei  alle
Mühe geben.

> Was motiviert Sie Xenomai zu favorisieren? Welche technischen Vorteile
> erwarten Sie? In welcher Anwendungsdomäne sehen Sie hier einen Vorteil
> gegenüber RT Preempt? Denken Sie, dass wir alle zusammen durch mehrere
> Implementierungen einen Vorteil bekommen? Denken Sie, dass Xenomai in
> den Vanilla Kernel Eingang finden wird?

Ich will die Diskussion um Vor-  oder  nachteile  dieser  oder  jener
Technologie hier nicht erneut aufwärmen. Das waren immer sehr hitzige
Diskussionen,  wo  technische  Argumente meist nur eine völlig unter-
geordnete Rolle spielten.

Ein paar Gründe habe ich oben schon genannt:

* Wir haben Kunden, die von verschiedenen proprietären RTOS zu  Linux
  wechseln wollen. Unter Xenomai stehen mir dafür entsprechende Skins
  zur   Verfägung,   die   komplett  simulirt  worden  sind  und  ein
  entsprechend hohes Maß an Zuverlässigkeit aufweisen.

* Der RT-Simulator erlaubt verschiedene höchst  clevere  Anwendungen;
  daß  ich im Debugger einen Breakpoint auf einer Code-Adresse setzen
  kann,  ist  selbstverständlich  -  aber  einen  Breakpoint  in  der
  Koordinate  "Zeit"  setzen  zu  können,  das habe ich woanders noch
  nicht gesehen. Und was das gerade bei der Simulation von  Echtzeit-
  abläufen bedeutet, brauche ich wohl nicht zu erklären.
  
Außerdem schätze ich an Xenomai, daß es ein  sehr  gut  lokalisierter
"Eingriff"  in den Linux-Kernel ist, den man als durchschnittlich be-
gabter Software-Entwickler nachvollziehen kann. RT Preempt  erfordert
dagegen  Eingriffe  an vielen Stellen, und bei jedem Treiber, der neu
in's Linux kommt, muß ich diesen reviewen und ggf. anpassen. Ich per-
sönlich bin einfach nicht clever genug, um das alles  zu  überblicken
und  garantieren zu können, daß man nichts übersehen hat - da braucht
es wohl Gurus wie Ingo Molnar. Deswegen machen wir einfach  das,  was
einfacher  ist  und  was wir daher schneller und in besserer Qualität
anbieten können.

Was das "Eingang in den Vanilla Kernel" finden betrifft: ich sehe das
nicht unbedingt als ultimatives Ziel an. Wir können  mit  vergleichs-
weise  geringem  Aufwand  dafür sorgen, daß auch aktuelle Kernel-Ver-
sionen von Xenomai unterstützt weren, und  wir  werden  entsprechende
Kernels  unseren Kunden bereitstellen. Auf der nächsten Version unse-
res ELDK wird Xenomai mit drauf sein. Für RT Preempt ist ein ungleich
höherer Aufwand erforderlich. Thomas könnte das sicher bestätigen.

Ob das eine richtige oder falsche Entscheidung ist, wird die Zeit und
die Raktion unserer Kunden zeigen.


Aber noch einmal: Ihnen als Anwender kann das eigentlich  egal  sein.
Ziel  der OSADL ist es, Standards zu schaffen, so daß ein RT-preempt-
basierter Kernel einfach  gegen  einen  solchen  mit  Xenomai  ausge-
tauscht werden kann.


[Ich will hier um Himmels willen keine Grundsatzdiskussion lostreten!
Daß wir hier bei DENX auf Xenomai setzen ist weder neu noch  irgendwo
von Bedeutung.]

Viele Grüße,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Use C++ to confuse your enemies; use C to produce stable code.