Re: Merging our x86 HALs
Javier Agustìn Fernàndez Arroyo <[email protected]>
| Newsgroups | gmane.os.reactos.kernel |
|---|---|
| Message-ID | <CAAHf8renipQnWE5Lf8jF_mOxGQykXpmABF9rVO0kMXyovu=ROg@mail.gmail.com> |
But this breaks modularity, isnt It? And HAL might become huge El 10/12/2017 19:11, "Colin Finck" <[email protected]> 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 > [email protected] > http://www.reactos.org/mailman/listinfo/ros-dev _______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev