Classic versus POSIX APIs

[Joel Sherrill <joel@OARcorp.com>]

Fabrício de Novaes Kucinskis wrote:
> Hello,
> 
> 
> I finished my studies of the RTEMS Classic API and now I'm starting to study
> 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 
this.

> 1) Is it very used? Who here uses the POSIX API? It appears to me that most
> 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 
questions.

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 API,
> 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, what
> 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 
semaphores.

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 OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985