[ag-automation] neuer Mitleser

[Robert Schwebel]

Hi Jan, 

On Sun, Apr 09, 2006 at 05:39:07PM +0200, Jan Kiszka wrote: Schade ist,
dass diese Diskussion nicht in
> Englisch stattfindet. Es gäbe noch einige Personen, die interessante
> Aspekte besteuern könnten.

Ok, it's probably time to change this thread to English. Let's follow
this policy for all "technical" OSADL lists. 

> Ich verstehe, dass das OSADL bemüht ist, ein einheitliches Bild der
> RT-Linux-Entwicklung nach außen abzugeben. 

As far as I understand the situation from our customer projects the main
argument is long term maintainability, while fulfilling the technical
aspects necessary for HRT - not the other way. 

> 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.

Yes, but IMHO these compatiblity layers have to sit ontop of
standardized POSIX userspace code. No need to fix it to some random
framework or HRT implementation. 

> 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.

I'm not involved into the Xenomai activities, but my impression was that
the Xenomai people are very serious with their maintainance concepts. I
think with regard to this topic there is no difference between the two
concepts. 

> Zur Sicherstellung der Wahlfreiheit bei der Treiberentwicklung wurde
> ferner RTDM entworfen. 

Can you tell us more about the usage scenario of RTDM? If I understand 
http://snail.fsffrance.org/www.xenomai.org/documentation/trunk/html/api/index.html
correctly it introduces lots of rt_* functions - is this overlayed by
"real" POSIX functions of for example the POSIX skin? 

> Dass dieser Ansatz bereits funktioniert, zeigen aktuelle Treiber, die
> allein durch Rekompilation zwischen Xenomai und RTAI austauschbar
> sind. 

The real question here is: are they exchangable between vanilla Linux
and Xenomai? 

> Vor einem halben Jahr tauchten auch erste RTDM-Treiber von
> Hardware-Herstellern auf. 

You know that this is no argument. Hardware manufacturers just look
what's there and usually don't have any experience with operating system
design. 

> 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.

RTAI was "the" way to go for several years - nevertheless it is the
wrong way if you take long term considerations into account. 

I know that you have done several really high level realtime linux
projects over the last years. But I'm absolutely sure that there will be
not much of that left over in the community if you have left university
and the community has to take over the activities.
 
> Bei allen inzwischen auch sichtbaren und im Detail beeindruckenden
> Fortschritten von Preempt-RT bleibt (meiner bescheidenen Einschätzung
> nach) noch genug zu tun: 

This is IMHO the really important discussion here: we should improve the
feature matrix.

> Hard-RT Userspace Mutexe (aktuell auf Soft-RT optimiert - was keine
> Abwertung sein soll), 

You have realized the recent PI mutex activities by Thomas and Ingo? 

	http://lwn.net/Articles/177111/

Chances are not too bad that this code goes into mainline in the near
future. 

> Stabilisierung der In-Kernel-API 

Sure. And this is definitely something the OSADL could for example help. 

> (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).

All this should go into the feature matrix. 

> 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.

2.4 is obsolete.

> 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.

If there is enough critical mass for a working group it should exist, as
long as it focusses on POSIX standard API HRT concepts. 

Nevertheless, I would like to see the activities focussed on RT-Preempt.
Following the next "hey-but-this-is-already-there" argumentation doesn't
buy us anything - it doesn't improve technology. RT-Preempt is currently
the only solution which has the potential to go into mainline, which is
the only guarantee for long term maintainability. Linux is a rapidly
moving target, and this is due to continuous improvement. If we today
propose to just go back to some random sub-sub community the game is
lost.

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9