[ag-automation] neuer Mitleser

[Robert Schwebel]

On Mon, Apr 10, 2006 at 10:29:20AM +0200, Jan Kiszka wrote:
> 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).

That was also the case in the good old RTAI days. It is a non-argument.
Problems usually arise when you go to non-mainstream architectures, have
non-mainstream environments and non-mainstream features. A long term
solution is about sitting ontop of a critical mass project, otherwhise
you won't benefit from the community model. 

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

So "rt_open()" would be "open()" when using the POSIX skin?

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

Well, but the technology was far from being what you expect from oss
code. RTAI was always a hell of crappy code internally. But we agree on
the fact that maintainance was the major problem. 

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

Is there enough critical mass behind for example RTnet? If you would
disappear as the maintainer, would there be enough community drive
behind the project to carry it on?

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

Well, reading until the end of the page usually helps ;) 

http://people.redhat.com/mingo/PI-futex-patches/

> > 2.4 is obsolete.
> 
> Don't tell this to me. ;)
 
I don't. You are just my rhetoric style medium =8-)

> We'll see, but I personally would not expect that merging everything
> into mainline of whatever project automatically solves the maintenance
> question. 

Surely not. But it improves the probability, and taken that OSADL plans
to professionally maintain an industrial tree, chances are not too bad.
And in the end there already _is_ significant commercial drive behind
RT-Preempt.

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

That's why the development of proper test cases and testing is an
important key part of the development process.  

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