(Outsider looking in, again. hello. Ignore me if needed)
It seems to me like you are discussing this from a pretty nebulous sense of 'why should we do this' and the same for 'we are scared of doing this'.So, concrete question, what sort of issues are you likely to run in to? You have had issues now with bugs that pop up only on some HAL's due to duplication of code. What are the negative consequences of doing this? What could potentially break? Why would really old hardware break, and can it be mitigated? And, if shit hits the fan, how hard would it be to backtrack again/make a dirty as hell hack at runtime?2017-12-13 12:49 GMT+01:00 Javier Agustìn Fernàndez Arroyo <elhoir@gmail.com>:The question in this last case is, how HAL supports new CPU instructions? but that`s an off-topic questionBut, speaking about the former, it would be wonderful to be able to run Windows software in such hardware.Supporting very old hardware means that it will consume very very fewer resources in very new hardware, too."supporting very old hardware, which I see as a plain and simple waste of resources."I completely disagree.On Wed, Dec 13, 2017 at 8:24 AM, Riccardo Paolo Bestetti <riccardo.kyogre@live.it> wrote:Hi David,
I was talking about supporting very old hardware, which I see as a plain and simple waste of resources. There may be legacy computers running legacy software around, but you can be sure that no one is gonna redeploy these computer, especially with a different software configuration (i.e. installing ReactOS instead of Windows [2000|XP|2003] on it). Of course I leave the (very) technical discussion about how to implement HALs to you.
BR.
Riccardo P. Bestetti
From: Ros-dev [mailto:ros-dev-bounces@reacto
s.org ] On Behalf Of David Quintana (gigaherz)
Sent: martedì 12 dicembre 2017 22:45
I think yes, on the fact that duplicate code is already causing bugs. Now wether we want to unify everything into one megaHAL, or compile multiple HALs fom the same codebase, or merge into two medium-sized HALs, that's what the discussion is meant to be about.
On 12 December 2017 at 22:00, Riccardo Paolo Bestetti <riccardo.kyogre@live.it> wrote:
My bi-annual IT guy peak:
Is there a real need to?
I think not.
B.R.
Riccardo P. Bestetti
From: Ros-dev [mailto:ros-dev-bounces@reacto
s.org ] On Behalf Of Javier Agustìn Fernàndez Arroyo
Sent: martedì 12 dicembre 2017 18:13
To: ReactOS Development List <ros-dev@reactos.org>
Subject: Re: [ros-dev] Merging our x86 HALs
Win8 does not support old hardware as ReactOS do!
El 12 dic. 2017 17:52, "Alex Ionescu" <ionucu@videotron.ca> 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 <colin@reactos.org> 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@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
_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
