[ag-automation] neuer Mitleser

[Jan Kiszka]

Robert Schwebel wrote:
> 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. 

I totally agree, especially on maintainability. It took me (as a slow
hacker) 30 min. to port Xenomai and RTnet to 2.6.16 - including the
mails to the maintainers of the updated subsystems (I-pipe and POSIX skin).

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

Yep. More precisely on top of the kernel ABI. The ABI may require
extensions to support former kernel-only code, but this is a footnote.

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

From the user perspective, RTDM adds a small amount of new kernel
services (like all Xenomai skins) which can both be used by non-POSIX
skins (native, VxWorks, etc., that's the rt_dev_ interface) or be mapped
on the original POSIX service as done inside the POSIX stub library.
[This is how it works under Xenomai and RTAI, but on Preempt-RT we would
of course use the existing file and socket infrastructure.]

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

If relevant vanilla kernel drivers or subsystems were directly usable
for HRT, already RTAI would have had some adoption layer for years.
Things may improve in the future under Preempt-RT (I'm the last who will
not welcome this), but there is still a lot to do. Moreover, the feature
to differentiate time-critical from non-time-critical invocations of
driver services is unique to RTDM so far.

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

RTAI failed widely due to its maintenance concept, not that much due to
its technology.

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

I take this as a compliment, but it's putting me too much into the
centre. Look at current activities and the people behind it.

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

Not yet, but it seems to be the announcement text. Typically, I prefer a
code review over documentation, and the aspects I'm referring to (risk
of -ENOMEM on mutex lock, hash chain lock dependencies on futex look-up,
tasklist_lock dependencies) were not mentioned in the announcements yet.

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

Don't tell this to me. ;)

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

We'll see, but I personally would not expect that merging everything
into mainline of whatever project automatically solves the maintenance
question. My poor experience from 4 years of maintaining or supporting
orthogonal out-of-tree RT projects is not that pessimistic about other
models. Clear separation helps to focus on the major aspects, and even
in a merged scenario, someone has to take care for them (e.g.
RT-properties).

Jan

-------------- 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/20060410/d3e5827f/signature-0001.pgp