[ag-automation] neuer Mitleser

[Jan Kiszka]

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

No, it wasn't (as long as you do not refer to pre-24-1.x, which was
before my time).

> Problems usually arise when you go to non-mainstream architectures, have
> non-mainstream environments and non-mainstream features. A long term

See blackfin port or IA64 support.

> solution is about sitting ontop of a critical mass project, otherwhise
> you won't benefit from the community model. 

Communities are moving, as well as their interests, and there is not
only one. Xenomai, e.g., strongly benefits from "the" community, check
the lists and and related projects. And it will surely benefit from a
kernel and glibc RT-community as well in the future.

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

Yes.

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

When looking at it from the public perspective, the impression might be
that there would no one, but not when looking at it from my inside view.
I'm fighting for this for years, but you likely also know how people
still prefer to remain silent over OSS usage.

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

For sure, I did (or what are you referring to?).

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

Jan

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