#
#  $Id$
#

This file contains information on the port of the OpenPalm package to RTEMS.
It is divided into the following Sections:

  + Status
  + Porting Notes/Comments

--joel
14 December 2000

mem.cxx needs fixing
alloca prototype...

Status 
======
+ Compiles -- untested.

+ Adding pthread_cond_timedwait to RTEMS would be ideal but for now,
  need to add error code to avoid timeout cases.

+ alloca() is missing from RTEMS tools for some reason.

+ settimeofday() needs to be added to RTEMS.

+ Link error on mnuDrawItem -- I don't know why.


Porting Notes/Comments
======================

This is the response to my initial inquiry from Tom M. Yeh
<tomyeh@infoshock.com>.

==========================================================================
I suggest you start TVM since it is designed with POSIX threads in mind
(of course, a simpler version). Here are some notes:

1. I separated the implementation into two layers: OS-dependent layer
(OSL) and OS-impendent layer (let us call it Anakin). The header file,
jedi/include__xxx__/os/thread.h, contains the definition of OSL about
threads. Functions are named with prefix mtOS if they are accessed only
internally, i.e., invisible to Anakin.

2. Like pThreads, OSL does has the concept of thread detaching while
Anakin doesn't. It simplified the porting job

3. Mutex is also the same as that of pThread except no attribute is
allowed. Again, to simplify the porting.

4. Cond is a little different: whether a cond will broadcast all or signal
one of pending threads is determined at the creation, mtInitCond with the
bBroadcast argument. On the other hands, pThreads supports
pthread_cond_signal and pthread_cond_broadcast at run time. The
incompatibility is due to that it is too costly to implement it in Windows
32API. Thus, to port to pThread-like OS, you have to maintain a data
member to know whether to broadcast or signal when SetCond is called.
==========================================================================

Joel's Note: 1-3 make the port simple although the interface uses some
functions that are beyond POSIX. For the routines beyond POSIX, we were
lucky enough that there were Classic API routines that were good matches.

