features supported in posix port

[Ralf Corsepius]

On Tue, 2004-12-07 at 16:02 +0000, Keith Robertson wrote:
> As suggested by my earlier post I'm interested in the posix port of 
> rtems (among others).
> 
> Previous list postings[*] seem to indicate that various features are not 
> supported in the posix port.  From what I can gather from mailing lists, 
> configure[**], and various .cfg files, I believe this is the status:
> 
> Supported:
> c++ (need to manually add -lstdc++ to the make-exe rule)
> 
> Not supported:
> libposix (no, according to bsp.cfg and target.cfg)
> networking (no,according bsp.cfg BUT yes, according to target.cfg![***])
> itron (all cfg files say no)
> mp (all cfg files say no)
> rdbg (presumably not a lot of demand for this!)
> 
> AFAICT, no source from the posix (cpukit/posix/src) and networking 
> (cpukit/libnetworking/src) directories is compiled.  So this seems 
> reasonably definitive :)
> 
> Can anybody confirm if this is indeed the current status?
Yes, this basically matches the current status.

>   I am 
> particularly interested in the posix and networking features and am 
> willing to look into making the necessary changes to support these two. 
>   Any pointers/information/places to start looking about how to add 
> support for these features would be very useful.  Information as to why 
> they aren't currently supported might also be useful.
In short: Laziness to avoid having to deal with various problems lurking
inside of the unix/posix BSP.

Somewhat more verbose:
Unix/posix is a set of user-space application libraries build on top of
an host-OS.
For embedded targets, RTEMS is a set of libraries implementing the OS,
containing kernel, drivers, kernelspace and users space libs "munged"
into one single address space.

This has various implications on RTEMS, esp. on cpukit/posix (pthreads)
and networking support:

* ATM, cpukit/posix is strongly tied to newlib and exploits newlib
internals.
Resolving these issues (Implementing RTEMS pthreads as userspace
threads; Further separation of cpukit/posix from newlib), probably is
possible, but so far nobody seems to have been sufficiently interested
in this topic to work on it. I would expect this to be doable, but not
to be an easy task.

* networking has similar issues as pthread support. Additionally,
further problems arise from RTEMS using "one address space for
everything" and from interaction with the host's kernel and hardware
resources.
I would expect resolving these issues to be difficult, at least not
without massive changes to RTEMS.

I.e. all in all, disabling various RTEMS features for unix/posix is just
a lazy, conservative, somewhat sloppy hack to enable only those features
known to work and to avoid having to cope with all the problems enabling
these features would reveal. It probably can be made more fine-grained,
but so far, unix/posix has always been living on the edge of
deprecation, because of its very limited usefulness ;)

Ralf