POSIX

[joel at OARcorp.com (joel at OARcorp.com)]

On Tue, 11 May 1999, Jake Janovetz wrote:

>    I was wondering if there is a reason not to start using
> POSIX in all my code.  It seems that POSIX provides all the
> messaging, semaphores, and threading that RTEMS-native 
> does, so why not go for compatibility?

There is no reason not to go for compatibility if that is what you want.
:)

>  Is there another issue here?

Some features are available in the Classic API that are not in the POSIX
API and vice-versa.  For exapmle, the rate monontonic periods in the
Classic API have no counterpart.

For interrupts, initialization, io, etc.  there is no POSIX counterpart.

POSIX provides at least keys and condition variables that have no
counterpart in the Classic API.

FYI your decision path is something RTEMS happily supports.  Choose the
API that suits you best.  I would love to see RTEMS support other APIs to
widen the choice.  If you were migrating from an in-house RTOS, you could
even implement it for legacy code and migrate your internal development to
POSIX.

> Is performance matched by the POSIX compliant stuff?

It should be comparable to the Classic API but there are no benchmarks to
back up this statement.  Since they are based on the same core operations,
the design says the performance should be comparable.

>    Clearly, I'm somewhat naive about what POSIX provides, but
> it seems to me it will leave a more portable program in its
> wake.

It should.  

Be warned that you may end up finding a hole in what RTEMS provides
POSIX-wise.  But adding a POSIX routine here or there in the interest of
increased application portability is a small tradeoff.

--joel