APIs: POSIX versus Classic
Gedare Bloom
gedare at rtems.org
Thu Aug 15 12:55:49 UTC 2013
For code that you plan to migrate between RTEMS and desktop
environments I advise sticking to POSIX. In the past I have worked on
some adapter layers for some of the classic RTEMS, but there is a lot
that is non-portable if you use classic RTEMS services.
-Gedare
On Thu, Aug 15, 2013 at 8:41 AM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
> On 08/05/2013 02:43 AM, Sebastian Huber wrote:
>>
>> Hello,
>>
>> the only reason why the POSIX API is optional is that you can save some
>> code
>> and data space in applications that don't need it. It helps also to
>> reduce the
>> code size to be reviewed.
>
> But underneath they are both instances of SuperCore Thread with
> different attributes set. There is some extra data to track the POSIX
> API features like signal sets, etc. and the minimum code added is
> mostly initialization.
>
> The overhead used to be a lot worse. But anything you can leave
> out is better.
>
> The Classic API is based on a proposed standard that was effectively
> pSOS+'s API. That style of API is visible in RTEMS, Nucleus, and ThreadX.
> It has some features that are not present in POSIX.
>
> You can mix APIs. A POSIX thread for example can use a Classic API
> Rate Monotonic period object. Or a Classic API task can use a
> POSIX mutex.
>
> It also means that you port a library once and any style task/thread
> can use the library without worrying about what RTEMS services you
> used to port it.
>
> The key benefit is being able to share code with UNIX-based hosts
> easily. :)
>
> Sorry to pile on late but this mix of APIs and standards really has
> benefits.
>
>> On 2013-08-05 06:28, Nick Withers wrote:
>>>
>>> Hi all,
>>>
>>> Quick one (hopefully :-P): Is there a "preferred" RTEMS API for new
>>> code? The POSIX API's considered production-ready, I believe...?
>>
>> The asynchronous cancellation is not production ready from my point of
>> view,
>> but this is a questionable concept on its own.
>>
>>> Ideally, I'd use the POSIX API for increased portability, methinks.
>>>
>>> Cheers!
>>>
>> The POSIX thread support enables you to use a lot of common third party
>> libraries.
>>
>
>
> --
> Joel Sherrill, Ph.D. Director of Research& Development
> joel.sherrill at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35806
> Support Available (256) 722-9985
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
More information about the users
mailing list