[ag-automation] neuer Mitleser

[Wolfgang Grandegger]

Robert Schwebel wrote:
> On Thu, Apr 06, 2006 at 04:38:31PM +0200, Wolfgang Denk wrote:
>> Welchen Nutzen hätte die? Diese Diskussionen hat es auf diversen
>> Mailinglisten immer wieder gegeben. Das Ergebnis war Null. Das
>> brauchen wir wirklich nicht wiederholen.
> 
> Wo hat es die konkret mal gegeben, und zwar in neuerer Zeit? Ich habe
> keine gesehen. 
> 
> Mich interessiert einfach mal Dein Statement im Kreis der OSADL
> Technik-Runde; Thomas' Position ist ja hinreichend bekannt.

OK, dann werfe ich meine Position in den Ring (siehe unten).

>> Es geht doch definitiv nicht darum, daß jemand auf RT preempt ver-
>> zichten und statt dessen aof Xenomai umsteigen will, oder?

Well, sagen wir auf RTDM umzusteigen. Das Real Time Driver Model ist 
nicht mit Xenomai verheiratet (Xenomai wird für die Referenz- 
implementierung benutzt). Es ist z.B. auch für RTAI verfügbar und es ist 
auch möglich, es auf Linux mit RT preempt zu portieren. Für einen 
erfahrenen Kernel-Hacker sollte das mit mäßigem Aufwand machbar sein.

Und RTDM ist nur das Treiberinterface. Xenomai stellt dem Benutzer 
darüberhinaus die RT facilities im User (und Kernel) space zur 
Verfügung. Dabei hat der Benutzer die Wahl zwischen verschiedenen Skins 
(Native, POXIS, VxWorks, etc). Bei der Verwendung der POSIX skin ist die 
Kompatibilität mit Linux (weitgehend) gewährleistet. Das was native 
Linux bietet ist aus meiner Sicht nicht vollständig.

> Wenn es wirklich so geht, daß jemand, der gegen den OSADL Realtime
> Standard (whatever that is) implementiert, nehmen kann, was er will,
> ist's ja ok. Wenn nicht, bin ich dafür, daß das OSADL eine eindeutige
> Richtung vorgibt - wir wollen _eine_ Automation Realtime Community,
> kein Community Splitup.
> 
> Das Ziel muß sein, daß ein Hardware-Hersteller weiß, daß er für sein
> Steuerungsboard, seine I/O-Karte oder sein Feldbus-Interface einen
> Treiber nach OSADL Standard bereitstellt und alle damit glücklich sind.

Dito, Ziel muss es sein, dass der Hardware-Hersteller sich auf das 
Schreiben der Treiber konzentrieren kann und ihm dabei auch komplette RT 
facilities angeboten werden, mit denen er seine Applikationen 
implementieren bzw. portieren kann.

>>> Treiberfrage schon nicht mehr, weil man eben sicher keinen Treiber
>>> für Preempt-RT == Vanilla Linux und für Xenomai schreiben kann. Hier
>>> müßte
>> Warum nicht? RT Preempt heißt doch Echtzeit im User-Space, und da kann
>> man sich sehr wohl auf standardiserte Interfaces einigen. RTDM ist da
>> m.E. ein exzellenter Ansatz.
> 
> Kannst Du mir bei RTDM auf die Sprünge helfen? Warum braucht man das?
> Warum nimmt man nicht einfach einen _normalen_ Treiber, sondern muß
> wieder was neues erfinden? 

Das ist der Preis für den separaten Echtzeitkontext.

> 
> Ich stecke in der aktuellen Xenomai-Entwicklung nicht drin, aber letztes
> Mal, als ich z.B. den RTnet Code angeschaut habe, war das vor allem Code
> Duplication, man forkt irgendwann den Linux Mainline Treiber und
> frickelt so lange an ihm rum, bis er alles hat was man braucht. Dabei
> vergißt man die Hälfte (weil's im eigenen Szenario nicht nötig ist),
> man koppelt sich von der Mainline Entwicklung ab und dupliziert allen
> Code. Das kann nicht das Ziel sein, weil es die Maintainance Probleme
> nicht trifft.

Es wird immer so getan, als wenn mit RT Preempt alle Echtzeitprobleme im 
Linux erschlagen werden. Dem ist aber nicht so, z.B. der Linux Netzwerk- 
stack ist damit noch langen nicht echtzeitfähig.

> Siehst Du grundlegende Hinderungsgründe, warum ein Mainline-Treiber
> nicht an die Erfordernisse der Echtzeit-Situation angepaßt werden kann?
> Falls ja, würde mich Thomas' Meinung dazu mal interessieren.

Ich kenne den RT preempt patch nicht sehr genau. Meine Versuche ihn auch 
PowerPC zum laufen zu bekommen, waren bisher erfolglos. Hier meine Sicht 
der Dinge (bitte mich gegebenenfalls korrigieren):

- RTDM/Xenomai bietet bereits heute eine stabiles RT framework zum
   entwickeln von OSADL-Treiberrn. Die Prozessorarchitekturen i86, ppc,
   arm, etc. sind bereits vollwertig unterstützt.

- RTDM kann auch über Linux mit RT preempt portiert werden. Damit würden
   beide Ansätze unterstützt werden.

- Ob RT preempt wirklich im Kernel integriert wird ist noch unklar. Und
   wenn, dann nur in kleinen Häppchen und das braucht Zeit. D.h. RT
   preempt wird wohl noch lange Zeit ein "moving target" bleiben. Das
   macht die Maintanance auch nicht einfach.

- RT preempt macht nur den Kernel echtzeitfähig(er). Einige Echtzeit
   facilities, vor allem im User-space fehlen. OK, das ist für das
   schreiben der Treiber unerheblich, aber dazu gehören ja auch Echtzeit-
   applikationen. Zudem fehlen real-time timer facilities.

Ich habe einige "schlechte" Sachen über RT preempt gehört und zudem ein 
paar Frage dazu. Könnte bitte jemand dazu Stellung nehmen:

- Gibt es Probleme mit der GLIBC in Verbindung mit dem RT preempt patch?

- Wie sieht es mit der Unterstützung andere Architekturen aus?

- Stimmt es, dass man aktuelle Treiber mit der RT preempt patch
   überarbeiten muss?

- Wie sieht es mit der Stabilität aus?

- Wie werden real-time timer facilities bereitgestellt?

- Gibt es bereits Echtzeitanwendung, die RT preempt einsetzen?

Was auch wirklich fehlt ist ein echter Vergleich beider Ansätze, vor 
allem auf kleinen embedded Systemen.

Viele Grüße.

Wolfgang.