RES: Classic versus POSIX APIs

Fabrício de Novaes Kucinskis fabricio at
Mon Jan 9 11:22:40 UTC 2006


Thank you for the answer. I have no more questions concerning the use of the
POSIX and Classic, but I have one about the "New Chapters" document.

Did I have to ignore all of the chapters, or just the POSIX managers?
Because in that doc there's new POSIX managers and some RTEMS support tools.
Just to list them:

POSIX Managers in "New Chapters":
- Event Logging
- Process Dump Control
- Configuration Space
- Administration Interface

RTEMS Support Components in "New Chapters":
- Stack Bounds Checker
- Rate Monotonic Period Statistics
- CPU Usage Statistics
- Error Reporting Support
- Monitor Task

Once more, thanks for the help.
Best regards,


-----Mensagem original-----
De: Joel Sherrill <joel at> [mailto:joel.sherrill at]
Enviada em: sexta-feira, 6 de janeiro de 2006 19:24
Para: Fabrício de Novaes Kucinskis
Cc: RTEMS - Mailing List
Assunto: Re: Classic versus POSIX APIs

Fabrício de Novaes Kucinskis wrote:
> Hello,
> I finished my studies of the RTEMS Classic API and now I'm starting to
> the POSIX API. My goal is to define one of these two APIs to use in our
> applications - ITRON is out of the question.
> Compatibility is not the issue for us at this moment; we are just looking
> for what resources each API provides. So, I have three main questions
> concerning the use of the POSIX API:

Different purpose and goal is the primary difference between the two.
The Classic API was based on a standard designed for use in hard
real-time systems.  POSIX was based on UNIX and extended toward embedded
systems.  POSIX threads were not in the original standard.

The POSIX API is very good when you want to port code to/from UNIX.
It is the foundation on which most libraries are ported to RTEMS.
The GNU Ada run-time is ported to POSIX threads and RTEMS just leveraged

> 1) Is it very used? Who here uses the POSIX API? It appears to me that
> of the messages at the list involves the Classic API;

There are books on the POSIX API and it is more generally known in the
computing world.  So people tend to understand it better and ask fewer

FWIW when you --enable-posix, you are primarily enabling POSIX threads
and concurrency operations.  POSIX includes file IO and the standard C
library which are always available.

> 2) What is the advantages of POSIX API over the Classic? Just the managers
> shown in the "New Chapters" document (Event Logging, Process Dump Control,
> etc)? There are advantages of Classic API over the POSIX?

Ignore those.  They really need to be deleted.  They are for APIs
proposed but never finalized AFAIK.

Both APIs have features not found in the other.  For example, the
Classic API has timer functions and rate monotonic periods.  It has very
fine grained control over thread execution modes.  In contrast, the
POSIX API has at least condition variables, keys (in contrast to per
task variables), and message queues with priority based messages which
are not found in the Classic API.

> 3) Can I use both APIs in one application? I mean, if I use the Classic
> is it possible to use the Administration Interface Manager (just an
> example)? I'm almost sure the answer is a capital NO. But if is a YES,
> are the issues on this?

Yes you can mix APIs in the same application.  No big deal.  More people
do it than realize it.  If you write a POSIX thread which makes a socket
call, it will use a Classic API semaphore and Classic API events.
Similarly, POSIX termios functionality is implemented using Classic API

The only issues I know of are that the APIs are different.  POSIX thread
priorities run opposite numerically from the Classic API (1 is low in
POSIX, 1 is high in Classic). If a POSIX thread exits, it silently goes
away.  If a Classic API task exits, it is a fatal error.

Is the Administration Interface Manager, a "new chapter"?  If so, it
doesn't exist.  So the answer is NO you can't call it.

The big deal to the POSIX API is that it is POSIX.  It is standard.  If
you port code from UNIX, it will make POSIX calls.

> Thanks in advance and a Happy New Year for everybody!
> Fabrício de Novaes Kucinskis - DEA / INPE
> -----------------------------------------
> Divisão de Eletrônica Aeroespacial
> Instituto Nacional de Pesquisas Espaciais

Joel Sherrill, Ph.D.             Director of Research & Development
joel at                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

More information about the users mailing list