[ros-dev] HAL reorganisation

[Ge van Geldorp]

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.