Re: [ros-dev] HAL multi-targeted build

[Timo Kreuzer]

Am 16.03.2011 18:16, schrieb Pierre Schweitzer:
>   Hi,
>
>  currently working on HAL and HAL targets (ACPI, MP, UP and so on), I discovered a quite
> bad issue in our build process.
>  Just look at the function HalInitSystem@8 (halinit.c), depending on the build target we
> don't add the same code (look at CONFIG_SMP, which is only defined for HAL MP). But,
> currently, as we are building using HAL library for reducing code redudancy, this
> halinit.c file is only built ONCE. So, build targets aren't taken into account (MP,
> ACPI). 
Does ACPI have a compile time macro, like CONFIG_ACPI?

>   So, two choices, or we break that model, and forget
> about lib, and just keep base .rbuild (hal.rbuild, halacpi.rbuild, and so forth) with all
> files defined in those. 
That would increase build time.

>   Or with find something smarter better such as
> rebuilding the lib with the new flags for each build? 
That kindof defeats the
purpose of the libs, doesn't it?

>   Or finding a way to include .rbuild files in other
> rbuild files?
>
>  I'm not really sure about the way to proceed, that's why I "release"
> that question to the whole ML. Furthermore, could CMAKE be any use here? To facilitate the
> process? 
Most of hal does not depend on CONFIG_SMP. There are some uses of 
dependent code:
- use of KiAcquireSpinLock/KiReleaseSpinLock in pcibus.c => We could use 
KeAcquireSpinLock instead, which is in spinlock.c and compiled twice.
- call to KfAcquireSpinLock/KfReleaseSpinLock from wrappers 
KeAcquireSpinLock/KeReleaseSpinLock in misc.c => Those could be moved to 
spinlock.c to improve performance in UP case by avoiding an additional 
call and doing the raiseirql in place. Its not really neccessary though IMO.
- use of VECTOR2IRQL and IRQ2VECTOR in a few places => We could replace 
these by a arrays of UCHARs

I'm against wasting precious compile time for an MP hal that doesn't 
even work. And I would actually like to have the kernel being compiled 
the same way. I bet the performance improvements of inlining some 
spinlock code are really neglectable.

I'd even go as far as dropping UP support completely and hotpatching 
spinlock functions.

As for ACPI, We might do as Dmitry suggested and also detect it. Afaik 
our 1sr stage installer doesn't support detection, so the normal user 
has no ACPI support anyway.

Just my 2 cents,
Timo