Re: [ros-dev] Merging our x86 HALs

[David Quintana (gigaherz)]

I have to agree that reducing it to 2 HALs (one ACPI with multiprocessor
and such, that maybe is also used for single-cpu systems with ACPI), and a
legacy one for systems unable to handle ACPI+MP, sounds like a great idea.

On 12 December 2017 at 18:13, Javier Agustìn Fernàndez Arroyo <
elhoir(a)gmail.com&gt; wrote:

>   Win8 does not support old hardware as ReactOS do!
>
>  El 12 dic. 2017 17:52, "Alex Ionescu" &lt;ionucu(a)videotron.ca&gt; escribió:
>
> >   I would move to the Win8+ HAL Model -- a single
> > HAL for APIC, ACPI with
> >  runtime support for UEFI (if present) and MP (if present).
> >
> >  If people still want to run on a PIC VM (why???) or old computer, then we
> >  can also maintain the HAL PIC x86 for UP.
> >
> >  Hence there would only be 2 HALs.
> >
> >  Best regards,
> >  Alex Ionescu
> >
> >  On Mon, Dec 11, 2017 at 1:07 AM, Colin Finck &lt;colin(a)reactos.org&gt; wrote:
> >
> > >   Am 11.12.2017 um 01:18 schrieb Hermès
> > > BÉLUSCA-MAÏTO:> 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 kBHave you actually checked what makes up this
> > >  difference?
> > >  Hint: hal/halx86/legacy/bus/pci_vendors.ids
> > >
> > >
> > > >   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.
> > >
> > >  That doesn't mean we need to do the same. We can have one HAL for all
> > >  (Pentium and newer) x86 platforms. The overhead of additional checks at
> > >  boot-up is negligible. That should be a solution for 99% of the people
> > >  out there. The rest may still go and trim down our HAL to their needs.
> > >
> > >  But let's not pretend we can maintain multiple x86 HALs for all x86
> > >  computers out there. Do you really want to test X HALs with Y different
> > >  systems? Ensure that a legacy HAL runs on a modern ACPI system? What
> > >  would be the point?
> > >
> > >
> > > >   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?
> > >
> > >  Absolutely not! You need to reprogram the standard PICs also on an APIC
> > >  system, and this is precisely what both functions do. Put them into a
> > >  diff tool to see for yourself.
> > >
> > >  The same goes for timers. Even with the introduction of ACPI Timers,
> > >  Local APIC Timers, and Time-Stamp Counters, you still need a traditional
> > >  one (like RTC or PIT) for calibration at system startup. Simply because
> > >  the newer ones don't run at a known fixed frequency.
> > >  The Legacy HAL successfully employs an algorithm based on the RTC while
> > >  the APIC HAL unsuccessfully tries to use the PIT.
> > >
> > >
> > > >   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)
> > >
> > >  Tell me about a single one we cannot detect and which is worth to
> > >  support. I don't recall that we ever recommended our testers to choose a
> > >  different HAL at setup.
> > >
> > >
> > > >   And normally it's not the setup that decides
> > > > about the HAL, but the 
> > >  bootloader.
> > >
> > >  That defies your previous point about the setup initializing the
> > >  registry depending on the HAL.
> > >  If we can let the user select a Legacy HAL in the boot loader after
> > >  installing with an ACPI HAL, it is also technically possible to have one
> > >  HAL that encompasses both.
> > >
> > >
> > >  - 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
>