As most of you know, I'm dabbling around a little bit with a port of ReactOS to the Xbox. I think most of the differences between a standard PC and the Xbox can be handled by using a custom HAL for the Xbox, after all, that's what the HAL is for.
At the moment, we build 1 HAL, based on the value of MP in config it's either a UniProcessor HAL or a MultiProcessor HAL. Which code is compiled is based on preprocessor statements. I'd like to be able to build 3 HALs in parallel, the UP, MP and Xbox HALs. When installing ("make install"), the correct HAL would be selected based on the MP config var. When creating a boot cd, all three would be copied to the CD and the setup program would select the correct one to copy to the harddisk. This will allow us to build a single boot CD for different configurations. I'm aware that we'll need a NTKRNLMP.EXE on the boot CD too (I will try very very hard not to need a different kernel for Xbox) for this "single boot CD" idea to work, but that's a different problem and I'd like to tackle that later.
The three HALs will share a lot of the code. To avoid code duplication, I propose to create a directory structure like this:
hal | --- hal | --- halx86 | | | +----- generic | | | | | +----- include | | | +----- up | | | +----- mp | | | +----- xbox | +-- hal68k :-) | +-- etc...
The "generic" subdir will contain most of the code. The "up" subdir will contain mostly simple .c files which just include a .c file from generic. For example, the HalMakeBeep() function will be defined in generic/beep.c. In "up" there will be a file beep_up.c which contains only 'include "beep.c"', which will be compiled with the include path set to "../generic". The "mp" and "xbox" directories can either include "generic" files or have their own implementation of a given routine (e.g. display_xbox.c for HalDisplay* functions on the Xbox).
Doing it this way we should have little code duplication and our dependency tracking system should work.
Comments?
Gé van Geldorp.