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
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
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@gmail.com> wrote:
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
Now the only problem is that neither our APIC nor MP HAL actually work...
On 2017-12-12 18:31, David Quintana (gigaherz) wrote:
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@gmail.com> wrote:
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
i know you probably can't answer, but.... where is the ninja group? xD
On Tue, Dec 12, 2017 at 7:06 PM, Thomas Faber thomas.faber@reactos.org wrote:
Now the only problem is that neither our APIC nor MP HAL actually work...
On 2017-12-12 18:31, David Quintana (gigaherz) wrote:
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@gmail.com> wrote:
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
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@reactos.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.camailto: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.orgmailto: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.orgmailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.orgmailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
To remember what the ReactOS project is about : it’s about recreating Windows in open-source and trying not to do the same mistakes as the non-open-source counterpart, i.e. having it work only on the newest of the newest computers.
And also, it’s not like if the HAL PIC x86 UP would suddently not work anymore: its “maintenance” is very minimal (bug fixes).
Otherwise, Alex’ idea of two HALs sounds nice.
Regards,
Hermès
De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Riccardo Paolo Bestetti Envoyé : mardi 12 décembre 2017 22:01 À : ReactOS Development List Objet : Re: [ros-dev] Merging our x86 HALs
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@reactos.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
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@reactos.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
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@reactos.org] On Behalf Of David Quintana (gigaherz) Sent: martedì 12 dicembre 2017 22:45 To: ReactOS Development List ros-dev@reactos.org Subject: Re: [ros-dev] Merging our x86 HALs
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.itmailto: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@reactos.orgmailto:ros-dev-bounces@reactos.org] On Behalf Of Javier Agustìn Fernàndez Arroyo Sent: martedì 12 dicembre 2017 18:13 To: ReactOS Development List <ros-dev@reactos.orgmailto: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.camailto: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.orgmailto: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.orgmailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.orgmailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.orgmailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
"supporting very old hardware, which I see as a plain and simple waste of resources." I completely disagree.
Supporting very old hardware means that it will consume very very fewer resources in very new hardware, too. But, speaking about the former, it would be wonderful to be able to run Windows software in such hardware.
The question in this last case is, how HAL supports new CPU instructions? but that`s an off-topic question
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@reactos.org] *On Behalf Of *David Quintana (gigaherz) *Sent:* martedì 12 dicembre 2017 22:45
*To:* ReactOS Development List ros-dev@reactos.org *Subject:* Re: [ros-dev] Merging our x86 HALs
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@reactos.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
(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?
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
2017-12-13 12:49 GMT+01:00 Javier Agustìn Fernàndez Arroyo <elhoir@gmail.com
:
"supporting very old hardware, which I see as a plain and simple waste of resources." I completely disagree.
Supporting very old hardware means that it will consume very very fewer resources in very new hardware, too. But, speaking about the former, it would be wonderful to be able to run Windows software in such hardware.
The question in this last case is, how HAL supports new CPU instructions? but that`s an off-topic question
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@reactos.org] *On Behalf Of *David Quintana (gigaherz) *Sent:* martedì 12 dicembre 2017 22:45
*To:* ReactOS Development List ros-dev@reactos.org *Subject:* Re: [ros-dev] Merging our x86 HALs
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@reactos.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
(Oh, and, is anyone willing to actually do the work involved and take it under their wing?)
2017-12-13 13:02 GMT+01:00 Magnus Johnsson magnusjjj@gmail.com:
(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?
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link <#m_-3948499177932828522_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
2017-12-13 12:49 GMT+01:00 Javier Agustìn Fernàndez Arroyo < elhoir@gmail.com>:
"supporting very old hardware, which I see as a plain and simple waste of resources." I completely disagree.
Supporting very old hardware means that it will consume very very fewer resources in very new hardware, too. But, speaking about the former, it would be wonderful to be able to run Windows software in such hardware.
The question in this last case is, how HAL supports new CPU instructions? but that`s an off-topic question
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@reactos.org] *On Behalf Of *David Quintana (gigaherz) *Sent:* martedì 12 dicembre 2017 22:45
*To:* ReactOS Development List ros-dev@reactos.org *Subject:* Re: [ros-dev] Merging our x86 HALs
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@reactos.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
Supporting old hardware does not mean it will consume fewer resources. The fact that you’re carefully optimizing the code, because it has to run on old hardware, means that it will consume fewer resources. And nothing in particular stops you from doing that even without supporting old hardware.
It would be wonderful indeed, but one has to draw the line somewhere. What I was proposing is to draw the line in a useful place, i.e., in a place that would have ReactOS support hardware that is actually of any interest for new setups.
I gave a variation of this argument when discussing what NT version(s) ReactOS should target. Let me give a slightly updated variation today.
It seems to me that this project is terribly undermanned. Today, the codebase is missing most of what makes an OS modern and useful, and at this pace, even if you target the most modern Windows OS currently in existence, the gap is going to get bigger. Targeting legacy systems is not going to do any good. Unless you only want to run on legacy systems, that is. Let’s say for the sake of argument that that is the case. How many systems have legacy hardware *and* can’t be replaced with newer systems *and* are likely to break down (i.e. non-redundant hardware or insufficient maintenance), *and* are not just getting a cloned image of whatever was installed on there before in case they do break down? Because these would be the only possible candidates for such a ReactOS. Other that 14 years old tech-savvy kids trying to resuscitate their father’s old PC and Christian youth organizations fixing old PCs for the local Community, but I doubt this is what any of you think as your target.
one of the companies I work for, every year we make a list of the older computers, and we change them. Every time this happens, I try to install the latest ReactOS and to run their CRM software on there, with the hope that one day I will be able to experimentally run one of these computers with ReactOS. The last two times I tried this, it was worse than the year before. And yet, the discussion is whether to support legacy hardware. This is why I said it is, plain and simple, a waste of resources. It is. 28 years ago GEOS 2.0 was released for the C128. 22 years ago Windows 95 was released for “legacy hardware”. ReactOS is many years away from becoming usable. You do the math…
Thank you for the time you took to read this.
BR, Riccardo P. Bestetti
From: Ros-dev [mailto:ros-dev-bounces@reactos.org] On Behalf Of Javier Agustìn Fernàndez Arroyo Sent: mercoledì 13 dicembre 2017 12:49 To: ReactOS Development List ros-dev@reactos.org Subject: Re: [ros-dev] Merging our x86 HALs
"supporting very old hardware, which I see as a plain and simple waste of resources." I completely disagree. Supporting very old hardware means that it will consume very very fewer resources in very new hardware, too. But, speaking about the former, it would be wonderful to be able to run Windows software in such hardware. The question in this last case is, how HAL supports new CPU instructions? but that`s an off-topic question
On Wed, Dec 13, 2017 at 8:24 AM, Riccardo Paolo Bestetti <riccardo.kyogre@live.itmailto: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@reactos.orgmailto:ros-dev-bounces@reactos.org] On Behalf Of David Quintana (gigaherz) Sent: martedì 12 dicembre 2017 22:45
To: ReactOS Development List <ros-dev@reactos.orgmailto:ros-dev@reactos.org> Subject: Re: [ros-dev] Merging our x86 HALs
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.itmailto: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@reactos.orgmailto:ros-dev-bounces@reactos.org] On Behalf Of Javier Agustìn Fernàndez Arroyo Sent: martedì 12 dicembre 2017 18:13 To: ReactOS Development List <ros-dev@reactos.orgmailto: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.camailto: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.orgmailto: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.orgmailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.orgmailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.orgmailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.orgmailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi,
I think that at least merging most of the versions shouldn't be a big problem. We could go Win8's way. Is there a rough estimation, how much is the distribution of common code, code for new HW only and code für old HW only?
To be honest, I don't think that much space will be wasted in the installation or during runtime if we merge all (generic) hals to one.
If I understand it correctly, even on modern HW we need most of the "old" ways for initialization. The biggest waste should be the ACPI infrastructure on very(!) old HW. And this is how many KB on RAM? 200KB?
Btw, ACPI went into the mass market ca. 1998. On these days, 32 MB RAM were normal. ReactOS wouldn't even boot on these machines.
Best regards, Michael Fritscher
That's why I'm extremely in favour of keeping the HAL x86 Standard PC mono-processor separate from the other hals (I mean, as a separate dll). But if you find inside some code that can be shared with the ACPI/APIC/whatever other hal, then just share it! (maybe use some #ifdefs inside as long as it doesn't imply recopying twice the file contents into the ifdef blocks).
Regards
-----Message d'origine----- De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Michael Fritscher Envoyé : mercredi 13 décembre 2017 23:06 À : ros-dev@reactos.org Objet : Re: [ros-dev] Merging our x86 HALs
Hi,
I think that at least merging most of the versions shouldn't be a big problem. We could go Win8's way. Is there a rough estimation, how much is the distribution of common code, code for new HW only and code für old HW only?
To be honest, I don't think that much space will be wasted in the installation or during runtime if we merge all (generic) hals to one.
If I understand it correctly, even on modern HW we need most of the "old" ways for initialization. The biggest waste should be the ACPI infrastructure on very(!) old HW. And this is how many KB on RAM? 200KB?
Btw, ACPI went into the mass market ca. 1998. On these days, 32 MB RAM were normal. ReactOS wouldn't even boot on these machines.
Best regards, Michael Fritscher
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Two HALs for both old and new hardware is good.
I've tried XP on new hardware and it did not boot up at all.
ReactOS same or better.
On Tue, Dec 12, 2017 at 10:51 AM, Alex Ionescu ionucu@videotron.ca wrote:
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
-
Alex Ionescu -
David Quintana (gigaherz) -
Hermès BÉLUSCA-MAÏTO -
James Tabor -
Javier Agustìn Fernàndez Arroyo -
Magnus Johnsson -
Michael Fritscher -
Riccardo Paolo Bestetti -
Thomas Faber