[ag-automation] neuer Mitleser

[Jan Kiszka]

Hallo allerseits,

als Spät-Subscriber (bislang war es hier ja eher ruhig) möchte ich noch
ein paar Ergänzungen zu diesem spannenden Thread vornehmen, obgleich
Thomas und Wolfgang die Situation schon für meine Begriffe sehr treffend
dargestellt haben. Schade ist, dass diese Diskussion nicht in
Englisch stattfindet. Es gäbe noch einige Personen, die interessante
Aspekte besteuern könnten.


Ich verstehe, dass das OSADL bemüht ist, ein einheitliches Bild der
RT-Linux-Entwicklung nach außen abzugeben. Die Realität ist dennoch
komplexer. Ebenso wenig wie vermutlich Xenomai RTAI oder RTLinux
vollständig ablösen wird, stellt Preempt-RT einen Ersatz von Xenomai
dar. Es gibt Anforderungen in der Industrie wie Legacy-RTOS-Code,
Kernel-Versionsabhändigkeiten, Maintainability, kalkulierbare
Worst-Case-Performance oder Usability, bei denen jede der Lösungen ihre
Stärken und Schwächen besitzt.

Mit dem Ziel, in dieser auch zukünftig differenzierten Situation
API-Stabilität und Flexibilität zu bieten, wurde Xenomai geschaffen.
Dabei ist es keineswegs auf den Dual-Kernel-Ansatz festgelegt. Es ist
kein Geheimnis, dass Preempt-RT in Zukunft eine reizvolle Plattform für
dieses Projekt bieten könnte (die Pläne sind alt). Aber auch das
Dual-Kernel-Konzept ist in Xenomai noch nicht ausgereizt. Vielmehr wurde
hier eine bewusst konservative Implementierung gewählt, um nicht in die
RTAI-Falle zu tappen, sondern zunächst eine stabile Basis zu schaffen.

Zur Sicherstellung der Wahlfreiheit bei der Treiberentwicklung wurde
ferner RTDM entworfen. Dass dieser Ansatz bereits funktioniert, zeigen
aktuelle Treiber, die allein durch Rekompilation zwischen Xenomai und
RTAI austauschbar sind. Vor einem halben Jahr tauchten auch erste
RTDM-Treiber von Hardware-Herstellern auf. Und wir hätten fast schon
eine RTDM-Implementierung über Preempt-RT ankündigen können (für RTnet),
wäre nicht die Differenz zwischen Preisvorstellung des potenziellen
Auftraggebers und tätsächlichem Aufwand zu groß gewesen. Die Zahl der
RTDM-Projekte wächst stetig (RTnet, CAN, Comedi, USB, Firewire, sowie
zahlreiche unveröffentlichte Entwicklungen) und fokussiert dabei
wertvolle Ressourcen der RT-Community.


Bei allen inzwischen auch sichtbaren und im Detail beeindruckenden
Fortschritten von Preempt-RT bleibt (meiner bescheidenen Einschätzung
nach) noch genug zu tun: Hard-RT Userspace Mutexe (aktuell auf Soft-RT
optimiert - was keine Abwertung sein soll), Stabilisierung der
In-Kernel-API (hrtimer, Interrupt-Handling - threaded or non-threaded
für RT?), neue Architekturen, systematische Performanceanalysen,
Dokumenation verdeckter nicht-deterministischer Dienste (z.B.
select/poll oder bestimmte Signal-Dienste).

Aus Sicht des Xenomai-Projektes ist zudem abzuwarten, auf welchen
Wegen die RT-Änderungen ihren Gang in den Kernel nehmen und wie
robust sie sich gegenüber für Dual-Kernel typischerweise orthogonale
Änderungen am Mainline erweisen. Eine zu frühe Portierung würde die
Maintenance-Situation für Xenomai nur verschlechtern, da Ressourcen
bekanntlich begrenzt sind. Und für Kernel 2.4 bietet sich zudem keine
Alternative.


Abschließend würde ich gerne den Vorschlag aufgreifen, über eine
Xenomai- und/oder RTDM-Arbeitsgruppe im OSADL nachzudenken. Sicher würde
dieses Thema bei einigen Anwendern auf Interesse stoßen. Ein größerer
deutscher Maschinenbauer fragte mich z.B. neulich nach einer solchen
Austauschmöglichkeit. Als außen stehender Beobachter kann ich das hier
selbstverständlich lediglich anregen, würde aber versuchen, sofern es
erwünscht wäre und meine Zeit es erlaubt, ein solches Vorhaben zu
unterstützen.

Beste Grüße,
Jan Kiszka

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : https://lists.osadl.org/pipermail/ag-automation/attachments/20060409/66405922/signature.pgp