Re: [ros-dev] Merging our x86 HALs

[Hermès BÉLUSCA-MAÏTO]

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:[e-mail]] 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:[e-mail]] 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:[e-mail]] De la part de
> >  > Colin Finck Envoyé : dimanche 10 décembre 2017 19:55 À :
> >  > ros-dev(a)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(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev 
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev