This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project. See the eCos home page for more information.
> 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 `