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 < elh...@gmail.com> wrote: > But this breaks modularity, isnt It? > > And HAL might become huge > > El 10/12/2017 19:11, "Colin Finck" <co...@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 >
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev