[ECOS] Re: Use of ifdefs a hinderance for portability.

[Bart Veer <bartv@cygnus.co.uk>]

> Having had significant experience in porting and supporting a
> commercial multiprocessor real-time operating system to a number of
> processor architectures, (as well as numerous SBC and devices), I am
> concerned about the amount of "#ifdefs" in the startup and platform
> code. (The HAL)

I believe the situation is not as bad as you might think. Looking at
the PowerPC architectural HAL package and the cogent platform package,
the most popular #ifdefs are the following:

7 * CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
5 * CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT
5 * CYG_HAL_POWERPC_MPC860
3 * CYG_KERNEL_USE_INIT_PRIORITY
3 * CYG_HAL_STARTUP_ROM
2 * CYG_HAL_STARTUP_RAM
...

Many of the #ifdef's relate to the gdb support. The current
implementation of this is not as clean as it should be, but will be
improved. Unfortunately target-side debug stubs tend to be fairly
intrusive.

The three uses of CYG_KERNEL_USE_INIT_PRIORITY should really be
removed. These date from a time when the compiler support for this was
still experimental.

Switching between ROM and RAM startups has an impact on both the
linker script and the source code. I am not sure it is possible to
reduce the #ifdef's for these without making ROM and RAM systems
separate platforms, but that would involve duplicating a lot of other
code.

It is the five occurrences of MPC860 that justify concern. The current
implementation of the HAL basically operates at two levels:
architecture and platform (i.e. board). It should operate at three
levels, architecture, processor implementation, and platform. In fact
the existing documentation makes clear that this is how it should
work, but we did not have time before the release to actually organize
things that way. It is also possible that some of these #ifdef's are
not actually necessary, but they indicate areas where people porting
to other PowerPC variants should pay special attention.

Now that we have made a release and there are people out there who are
actually using the system and providing constructive feedback, ports,
etc. we can start to sort out issues like these. Things may not end up
exactly as you suggest. For example there is an argument for doing
device driver initialization by means of C++ static constructors with
suitable priorities. That way the platform code does not need to know
in advance which device drivers the user has selected. However your
comments will certainly be read and considered by the relevant people
in the eCos team.

There are already some instances of doing things on a function-level
basis rather than a #ifdef basis, for example the architectural _start
code invokes a function hal_hardware_init which should be provided by
the platform package. There are other cases such as the gdb support
and interrupt instrumentation where #ifdef's are the best way to
select the desired functionality, and we will continue to use them
when appropriate.

Bart Veer // eCos net maintainer
`