Guilherme Nelson DeSouza wrote:
>
> Content-MD5: OOlFYK/wh5UE91OtcrTMAA==
> X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc
>
> Thanks, Stuart. That is quite a contribution.
>
>
> >Date: Fri, 01 Oct 1999 10:56:53 +0100
> >From: Stuart Hughes <[EMAIL PROTECTED]>
> >Subject: Re: [rtl] POSIX design document
> >
> >...
> >
> >Note, in RTL POSIX is not a separate loadable module.
> >
>
> Isn't it true that RTL has a rtl_posixio module?
>
Yes. But these are to implement to open/close/read/write semantics (I
think to rt fifos).
What I am talking about is the POSIX 1003.1 (I think), which describes
POSIX threads API calls. In RTL these make up the base scheduler with
the older API build as compatibility calls. In RTAI the opposite
approach is taken, the base scheduler implements primitives (start task,
create semaphore ...) and the POSIX thread API is implemented in a
separate module that constructs the POSIX calls from the primitives
found in the base scheduler.
There is also a big difference between the coverage of the POSIX thread
API, as far as I know RTL does not have provision for priority
inheriting mutexes or condition variables. The discussion document
Victor put forward argues that these are 'bad' POSIX calls. This may be
true, but sadly we can't easily change the established API. The main
reason for having a POSIX threads API available is to try to provide a
portable abstraction that will let people with existing code move it
easily to the real time domain. This being the case, the POSIX thread
modules should provide as much API coverage as possible so that they can
truly provide a vehicle for portability.
Maybe the real question is whether POSIX (threads) is a suitable API for
real time, many other RTOS have some kind of POSIX compatibility, but
often people find it more usefull to program using the native API of
that RTOS.
>
>
> >Filename comparison
> >===================
> >
> >...
>
> Here I removed every thing that was "installation" dependent.
> I believe that at this moment, it's more important to focus on
> the differences in the "programming" point of view, right?
>
I think programming details and installation/API details are both
important. From observing this list, the most common cause of problems
seems to be related to installation issues. I believe that having a
common API and installation mechanism will help to hold together the two
camps, as users may use either interchangeably.
Regards,
Stuart
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
