Automatic manager initialisation (was: Re: How to enable IP Forwarding in RTEMS)

[Ralf Corsepius]

On Fri, 2004-06-04 at 04:48, Chris Johns wrote:
> Joel Sherrill wrote:

> > It might not work on all targets though.  It might be ELF
> > specific.
> 
> You could be correct. Which targets are not ELF ?
Several, however most (all?) of them are slowly going to be phased out:

Without having checked details, off-hand, these examples come to my mind:

* sh-rtems is in a transition from COFF to ELF: 
It is COFF with gcc < 3.4, binutils < 2.15 (sh-rtems == sh-rtemscoff)
and ELF with gcc >= 3.4, binutils >= 2.15 (sh-rtems == sh-rtemself).
* sh-rtemscoff is still supported in gcc >= 3.4, binutils >= 2.15,
rtems-4.7 but it is supposed to be phased out.

* AFAIK, i960-rtems is COFF, is still supported in rtems-4.6, but it had
been deprecated in gcc and therefore probably is non-functional in gcc
>= 3.0 (IIRC, it meanwhile has been removed from gcc)

* AFAICT, tic4x-rtems had been COFF until recently. ... but this target
is special in many ways.

IMHO, switching to ELF is a double sided sword. On one hand, it provides
nice features and is way better supported by the toolchains than other
object formats.
On the other hand, I would prefer RTEMS not to be based on _any_ object
format specific details, because this could prevent users from porting
RTEMS to specific targets or from using external libs or tools with
RTEMS. 

E.g. the main reasons why SH users might prefer COFF over ELF:
* The traditional object format for the SHes had been COFF. Therefore
they might want to continue using commercial (COFF-)libs or tools with
RTEMS.
* On the SHes, the size of ELF-objects is larger than the size of COFF
objects. On low-end targets, such as SH1/SH2s this increase in size is
critical. (Building the RTEMS samples w/ sh-rtemself fails because of
hitting the memory limits of this BSP (The memory limits are the
real-world settings of our old AMOS boards)

Ralf