HAL multi-targeted build

[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).

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.
Or with find something smarter better such as rebuilding the lib with the new flags for
each build?
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?

Regards,
P. Schweitzer

[Dmitry Gorbachev]

Hi!

Is a separate ACPI HAL really needed these days? It could detect ACPI
presence at boot time.

[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

[Pierre Schweitzer]

> >   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? 
Yes.

> >   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. 
Well, HAL isn't that big. It would more certainly
break maintainability.

> >   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? 
Most probably,
yes. But, one thing is sure, having an absolute generic lib sounds impossible.

For the rest, I had an other idea, to complete the changes you talked about: getting the
HAL entry point out of the libs.

Regards,
P. Schweitzer

[Pierre Schweitzer]

To those who may have missed the commit, I finally applied that idea:
>   For the rest, I had an other idea, to complete the
> changes you talked about: getting the HAL entry point out of the libs. 
It's
working quite good. And doesn't force to rebuild the whole lib. HAL MP entry point has
now the check for ntkrnlmp and other changes can be done (as some stuff for ACPI ;-)).

If anyone wants to work on ACPI HAL for GSoC, it's ready :-P.

[Javier Agustìn Fernàndez Arroyo]

guys, ewould be possible to add parameters for specific architectures?

let me explain a bit, probably you want to biuld an AMD64-optimized kernel
and/or HAL to get the advantages of the CPU flags and so.....

And maybe you also want to build another completely different CPU arch, with
different flags....

hope you undestand this email.. :P

question is.... would i be possible?

P.S.: Again, im thinking in Linux kernel :D

On Mon, Mar 21, 2011 at 1:56 AM, Pierre Schweitzer <
pierre.schweitzer(a)reactos.org&gt; wrote:

>   To those who may have missed the commit, I finally
> applied that idea:
> >   For the rest, I had an other idea, to complete
> > the changes you talked 
>  about: getting the HAL entry point out of the libs.
>  It's working quite good. And doesn't force to rebuild the whole lib. HAL MP
>  entry point has now the check for ntkrnlmp and other changes can be done (as
>  some stuff for ACPI ;-)).
>
>  If anyone wants to work on ACPI HAL for GSoC, it's ready :-P.
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Timo Kreuzer]

Am 21.03.2011 08:59, schrieb Javier Agustìn Fernàndez Arroyo:
>   guys, ewould be possible to add parameters for
> specific architectures? 
We already have that. Our config files are architecture specific and 
contain relevant options like optimization for specific cpus.
look into config-<arch>.rbuild