Colin: Are we talking merge and decide which method to use at runtime (boot flags or something), or compile-time merging of the source code but generating multiple final hals based on each possible configuration?
I'm assuming the former.
elhoir: Given the fact that some of the HAL implementations are already broken due to code duplication, I think modularity in this case has proven itself to be a BAD choice.
On 10 December 2017 at 19:21, Javier Agustìn Fernàndez Arroyo < elhoir@gmail.com> wrote:
But this breaks modularity, isnt It?
And HAL might become huge
El 10/12/2017 19:11, "Colin Finck" colin@reactos.org escribió:
Hi all,
I have been looking into our HALs recently on the promise that it is a huge mess that needs fixing. Well, as a start I could imagine merging our 6 possible x86 HALs (Legacy, ACPI, APIC, ACPI+APIC, SMP, SMP+ACPI) into a single one, even if Windows ships individual ones. I see many advantages of that:
- Less duplications and reduced mess: Right now, the APIC HAL hangs at
HalpCalibrateStallExecution during boot, a function that has been fixed and universally implemented in all non-APIC HALs. The APIC HAL also duplicates HalpInitializePICs as HalpInitializeLegacyPIC. If you look at the SMP code, it didn't even receive the last build system changes and has conflicting implementations for APIC functions. A single x86 HAL would ensure that all possible configurations are maintained.
- Future-proof: How is one going to implement newer features like x2APIC
with a structure like that? Would it get another HAL, be integrated into the APIC HAL, or what? We wouldn't have such problems with a single x86 HAL.
- Less setup work and testing: Currently, 1st stage setup detects the
computer type and installs the appropriate HAL. As such, every additional HAL needs to be added to 1st stage setup code. The user is also able to select a custom HAL during setup, even if it wouldn't work on the machine. We should give neither the user nor the setup the ability to decide. The HAL itself knows best at boot-up what features to enable and what not.
- Convenience: The same ReactOS installation could be used on several
different x86 computers.
So is this the way to go or do I miss something important?
Best regards,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev