APIs: POSIX versus Classic
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.
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:
>> the only reason why the POSIX API is optional is that you can save some
>> 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
>> 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
>> but this is a questionable concept on its own.
>>> Ideally, I'd use the POSIX API for increased portability, methinks.
>> The POSIX thread support enables you to use a lot of common third party
> 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
More information about the users