Comtrol eCos - Manual (Page 786)

Porting
The GNU C library sources may also prove very useful: for a normal Linux application it is the C library that
provides the startup code and the system call interface.
Other Unix Platforms
Porting to a Unix or Unix-like operating system other than Linux would be somewhat more involved. The first
requirement is toolchains: the GNU compilers, gcc and g++, must definitely be used; use of other GNU tools
such as the linker may be needed as well, because eCos depends on functionality such as prioritizing C++ static
constructors, and other linkers may not implement this or may implement it in a different and incompatible way.
A closely related requirement is the use of ELF format for binary executables: if the operating system still uses an
older format such as COFF then there are likely to be problems because they do not provide the flexibility required
by eCos.
In the architectural HAL there should be very little code that is specific to Linux. Instead the code should work
on any operating system that provides a reasonable implementation of the POSIX standard. There may be some
problems with program startup, but those could be handled at the architectural level. Some changes may also
be required to the exception handling code. However one file which will present a problem is
hal_io.h , which
contains various structure definitions and macros used with the system call interface. It is likely that many of these
definitions will need changing, and it may well be appropriate to implement variant HAL packages for the different
operating systems where this information can be separated out. Another possible problem is that the generic code
assumes that system calls such as
cyg_hal_sys_write are available. On an operating system other than Linux it is
possible that some of these are not simple system calls, and instead wrapper functions will need to be implemented
at the variant HAL level.
The generic I/O auxiliary code should be fairly portable to other Unix platforms. However some of the device
drivers may contain code that is specific to Linux, for example the
PF_PACKET socket address family and the
ethertap virtual tunnelling interface. These may prove quite difficult to port.
The remaining porting task is to implement one or more platform HAL packages, one per processor type that is
supported. This should involve much the same work as a port to
another processor running Linux .
When using other Unix operating systems the kernel source code may not be available, which would make any
porting effort more challenging. However there is still a good chance that the GNU C library will have been ported
already, so its source code may contain much useful information.
Windows Platforms
Porting the current synthetic target code to some version of Windows or to another non-Unix platform is likely
to prove very difficult. The first hurdle that needs to be crossed is the file format for binary executables: current
Windows implementations do not use ELF, instead they use their own format PE which is a variant of the rather
old and limited COFF format. It may well prove easier to first write an ELF loader for Windows executables, rather
than try to get eCos to work within the constraints of PE. Of course that introduces new problems, for example
existing source-level debuggers will still expect executables to be in PE format.
Under Linux a synthetic target application is not linked with the system’s C library or any other standard system
library. That would cause confusion, for example both eCos and the system’s C library might try to define the
printf function, and introduce complications such as working with shared libraries. For much the same reasons,
a synthetic target application under Windows should not be linked with any Windows DLL’s. If an ELF loader has
been specially written then this may not be much of a problem.
682