rbuild and HALs module optimization - Ros-dev

16 Sep 2007

If we don't have a ntoskrnl rbuild module for every supported architecture I
don't understand why we do have a separate HAL rbuild module for every
architecture (X86 , PowePC) and sub architecture (x86-Generic , x86-xbox ,
PowerPC-Generic)
Currently we have a very complicated logic to compile the appropriate HAL
with conditions (IF) and alias that point to the correct module for the
target architecture. At the end always two dlls are going to be generated
for every architecture hal_up and hal_mp so what's the reason to have a
specific module for every architecture and not two generic modules that
represent the two possible HAL modes (uniprocessor and multiprocessor) that
dynamically include the appropriate source code for the platform
(Architecture + Sub Architecture) being build?
For example :
<module name="hal_generic" >
            (common code to all architectures, sub architectures , UP and MP
HALs)
</module>
<module name="hal_up" installname="halup.dll">
            <library>hal_generic</library>
            <library>..
            (common files to all UP HALs)
            <if property="ARCH" value="i386">
                        (X86 common files to all X86 UP HALs)
                        <if property="OARCH" value="xbox">
                                    (xbox specific files)
                        </if>
            </if>
            </if propery="ARCH" value="powerpc">
                        (PPC common files)
            </if>
</module>
And the same for multiprocessor <module name="hal_mp"
installname="halmp.dll" /> both files can be simply copied to the install cd
and usetup will install the correct HAL renamed as hal.dll depending on the
user selection. IMHO it greatly simplifies the process and is a more elegant
solution than the current one.