Actually, this is parts of the HKLM\SYSTEM\ControlSet00x\Enum tree that are subject to the remark I made about HKLM\HARDWARE in my previous mail, while the HARDWARE hive is actually volatile (thus regenerated each time at boot).
H. > -----Message d'origine----- > De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Hermès > BÉLUSCA-MAÏTO > Envoyé : lundi 11 décembre 2017 02:03 > À : 'ReactOS Development List' > Objet : Re: [ros-dev] Merging our x86 HALs > > Also, there is (at least parts of) HKLM\HARDWARE tree that is built at > installation time from info obtained from the HAL that is suitable for your > platform, and that will be used for the rest of the life of your > Windows/ReactOS/... installation. So if you then think that you'll be able to > use > "the same ReactOS installation [...] on several different x86 computers" (to > quote you), it'll be a bit more complicated than that!!!! > > Besides this, I've a question about your observation that in the APIC hal (not > ACPI) there's different implementation of HalpCalibrateStallExecution and > HalpInitializePICs / HalpInitializeLegacyPIC . Isn't it precisely because > these > stuff are completely different from the standard PICs used in platforms for > which the standard HAL (and possibly the ACPI HAL) are used? > > For your x2APIC question, if this shares a good stuff wrt. APIC, then either > it > would be inside the same APIC HAL, otherwise there could be two HALs, APIC > and the other one, but made from common "generic" code + different code > that depend on the APIC vs. x2APIC. > > > 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. > > Actually we should, because the detection might not work (of course in our > simple case "ACPI UP/MP" vs. "Standard", it's simple, but think about other > platforms where there can be subtle differences), AND the fact that an > advanced user may want to specify one's HAL. And normally it's not the setup > that decides about the HAL, but the bootloader. The bootloader (ntldr / > winldr) > also has the capability of detecting the HAL to use and load, unless being > specified otherwise by a switch in the command-lines in boot.ini (ntldr) or > somewhere in the BCD (bootmgr/winldr). > > H. > > > -----Message d'origine----- > > De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Hermès > > BÉLUSCA-MAÏTO Envoyé : lundi 11 décembre 2017 01:18 À : 'ReactOS > > Development List' > > Objet : Re: [ros-dev] Merging our x86 HALs > > > > I personally think it's a bit "against" the philosophy of HALs, namely > > having a lightweight hardware abstraction layer code for different > > platforms. > > If you basically put all the HALs into one, then you obtain bloated > > stuff (which remains in memory for the whole life of the OS). Example: > > standard HAL is 1MB vs. ACPI HAL which is few kB. > > A bit more work and you could even get a monolithic kernel! Nah joking xD > > ... > > but not completely. > > > > Note that if Windows nowadays has only one hal, it's because they now > > support basically only one "architecture"/platform, namely, ACPI > > multiprocessor (to put it simple). It has its pros, but also a lot of cons. > > > > To solve the original problem you have encountered in our code, just > > introduce common/generic .c files containing the code that is similar > > everywhere, even at the level of all the hals, or at the level of > > (let's say) a given CPU "type" (x86, x64...), then there are the other > > .c that implement the different flavours of the procedures that depend on > > the > specific arch/platform. > > > > Like this: > > > > HALs > > +---- Generic code > > +---- HAL for a given arch #1 (e.g. x86) > > | +---- Generic code for this arch > > | +---- Code for standard (non-ACPI) HAL > > | +---- Code for ACPI HAL > > | +---- Code for a different HAL flavour (platform)? > > | +---- ... > > | > > +---- HAL for arch #2 > > | +---- Generic code > > | +---- Code for platform > > | +---- Code for second platform > > | +---- ... > > | > > +---- etc... > > > > This is very clear and maintainable. > > > > H. > > > > > -----Message d'origine----- > > > De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de > > > Colin Finck Envoyé : dimanche 10 décembre 2017 19:55 À : > > > ros-dev@reactos.org Objet : Re: [ros-dev] Merging our x86 HALs > > > > > > Am 10.12.2017 um 19:38 schrieb David Quintana (gigaherz): > > > > Colin: Are we talking merge and decide which method to use at > > > > runtime > > > > > > Exactly! We don't even need boot flags: Just like the setup > > > currently detects an ACPI-compliant computer, the HAL could do this at > boot-up. > > > It's also not too hard to detect the presence of an APIC. > > > > > > I think a universal HAL for every x86 machine wouldn't be noticeably > > > larger than an ACPI+SMP HAL. > > > > > > > > > - 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 _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
