12 Dec
2017
12 Dec
'17
7:36 p.m.
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(a)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(a)gmail.com> wrote:
Win8 does not support old hardware as ReactOS do!
>
> El 12 dic. 2017 17:52, "Alex Ionescu" <ionucu(a)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(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev