Re: [ros-dev] Merging our x86 HALs

[Colin Finck]

Thanks for the numerous replies! Let's stop at this point and not talk
this topic to death ;)
Even if we don't know yet how many HALs are to be kept, we agree on
reducing the number of HALs from the current 6. There is also no point
in a final decision on this until we have code to back it.

I have begun by deduplicating some code:
https://github.com/reactos/reactos/pull/193
It has also turned out that HalpCalibrateStallExecution was not broken
in the APIC HAL, but relied on the I/O APIC. Unlike the Local APIC, this
one is disabled by default in VirtualBox. When enabling it, the APIC HAL
fails at a later stage.
However, we may still merge both implementations of
HalpCalibrateStallExecution into a generic one at some point.


Cheers,

Colin

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Merging our x86 HALs

[James Tabor]

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  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  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

Re: [ros-dev] Merging our x86 HALs

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

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-boun...@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


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Merging our x86 HALs

[Michael Fritscher]

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

Re: [ros-dev] Merging our x86 HALs

[Riccardo Paolo Bestetti]

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-boun...@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.kyo...@live.it<mailto:riccardo.kyo...@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-boun...@reactos.org<mailto:ros-dev-boun...@reactos.org>] On 
Behalf Of David Quintana (gigaherz)
Sent: martedì 12 dicembre 2017 22:45

To: ReactOS Development List <ros-dev@reactos.org<mailto: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.kyo...@live.it<mailto:riccardo.kyo...@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-boun...@reactos.org<mailto:ros-dev-boun...@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<mailto: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" 
<ion...@videotron.ca&l

Re: [ros-dev] Merging our x86 HALs

[Magnus Johnsson]

(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 <magnus...@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_source=link_campaign=sig-email_content=webmail_term=icon>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
> <#m_-3948499177932828522_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> 2017-12-13 12:49 GMT+01:00 Javier Agustìn Fernàndez Arroyo <
> elh...@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.kyo...@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-boun...@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.kyo...@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-boun...@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" <ion...@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

Re: [ros-dev] Merging our x86 HALs

[Javier Agustìn Fernàndez Arroyo]

"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.kyo...@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-boun...@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.kyo...@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-boun...@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" <ion...@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 <co...@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 freq

Re: [ros-dev] Merging our x86 HALs

[Riccardo Paolo Bestetti]

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-boun...@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.kyo...@live.it<mailto:riccardo.kyo...@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-boun...@reactos.org<mailto:ros-dev-boun...@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<mailto: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" 
<ion...@videotron.ca<mailto:ion...@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 
<co...@reactos.org<mailto:co...@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

__

Re: [ros-dev] Merging our x86 HALs

[David Quintana (gigaherz)]

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.kyo...@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-boun...@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" <ion...@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 <co...@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

Re: [ros-dev] Merging our x86 HALs

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

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-boun...@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-boun...@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" <ion...@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 <co...@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

Re: [ros-dev] Merging our x86 HALs

[Riccardo Paolo Bestetti]

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-boun...@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" 
<ion...@videotron.ca<mailto:ion...@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 
<co...@reactos.org<mailto:co...@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<mailto:Ros-dev@reactos.org>
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org<mailto: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

Re: [ros-dev] Merging our x86 HALs

[Javier Agustìn Fernàndez Arroyo]

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 
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 <
>> elh...@gmail.com> wrote:
>>
>> Win8 does not support old hardware as ReactOS do!
>>>
>>> El 12 dic. 2017 17:52, "Alex Ionescu"  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  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

Re: [ros-dev] Merging our x86 HALs

[Thomas Faber]

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 <
elh...@gmail.com> wrote:


Win8 does not support old hardware as ReactOS do!

El 12 dic. 2017 17:52, "Alex Ionescu"  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  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

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 <
elh...@gmail.com> wrote:

> Win8 does not support old hardware as ReactOS do!
>
> El 12 dic. 2017 17:52, "Alex Ionescu"  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  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

Re: [ros-dev] Merging our x86 HALs

[Javier Agustìn Fernàndez Arroyo]

Win8 does not support old hardware as ReactOS do!

El 12 dic. 2017 17:52, "Alex Ionescu"  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  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

Re: [ros-dev] Merging our x86 HALs

[Alex Ionescu]

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  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

Re: [ros-dev] Merging our x86 HALs

[Colin Finck]

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

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:ros-dev-boun...@reactos.org] 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:ros-dev-boun...@reactos.org] 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:ros-dev-boun...@reactos.org] De la part

Re: [ros-dev] Merging our x86 HALs

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

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:ros-dev-boun...@reactos.org] 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:ros-dev-boun...@reactos.org] De la part de Colin
> > Finck Envoyé : dimanche 10 décembre 2017 19:55 À : ros-dev@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@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

Re: [ros-dev] Merging our x86 HALs

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

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:ros-dev-boun...@reactos.org] De la part de Colin Finck
> Envoyé : dimanche 10 décembre 2017 19:55
> À : ros-dev@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@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

Re: [ros-dev] Merging our x86 HALs

[Colin Finck]

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@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Merging our x86 HALs

[David Quintana (gigaherz)]

Colin: Are we talking merge and decide which method to use at runtime (boot
flags or something), or compile-time merging of the source code but
generating multiple final hals based on each possible configuration?

I'm assuming the former.

elhoir: Given the fact that some of the HAL implementations are already
broken due to code duplication, I think modularity in this case has proven
itself to be a BAD choice.

On 10 December 2017 at 19:21, Javier Agustìn Fernàndez Arroyo <
elh...@gmail.com> wrote:

> But this breaks modularity, isnt It?
>
> And HAL might become huge
>
> El 10/12/2017 19:11, "Colin Finck"  escribió:
>
>> Hi all,
>>
>> I have been looking into our HALs recently on the promise that it is a
>> huge mess that needs fixing. Well, as a start I could imagine merging
>> our 6 possible x86 HALs (Legacy, ACPI, APIC, ACPI+APIC, SMP, SMP+ACPI)
>> into a single one, even if Windows ships individual ones. I see many
>> advantages of that:
>>
>> * Less duplications and reduced mess: Right now, the APIC HAL hangs at
>> HalpCalibrateStallExecution during boot, a function that has been fixed
>> and universally implemented in all non-APIC HALs. The APIC HAL also
>> duplicates HalpInitializePICs as HalpInitializeLegacyPIC.
>> If you look at the SMP code, it didn't even receive the last build
>> system changes and has conflicting implementations for APIC functions.
>> A single x86 HAL would ensure that all possible configurations are
>> maintained.
>>
>> * Future-proof: How is one going to implement newer features like x2APIC
>> with a structure like that? Would it get another HAL, be integrated into
>> the APIC HAL, or what?
>> We wouldn't have such problems with a single x86 HAL.
>>
>> * Less setup work and testing: Currently, 1st stage setup detects the
>> computer type and installs the appropriate HAL. As such, every
>> additional HAL needs to be added to 1st stage setup code.
>> 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.
>>
>> * Convenience: The same ReactOS installation could be used on several
>> different x86 computers.
>>
>>
>> So is this the way to go or do I miss something important?
>>
>>
>> Best regards,
>>
>> 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

Re: [ros-dev] Merging our x86 HALs

[Javier Agustìn Fernàndez Arroyo]

But this breaks modularity, isnt It?

And HAL might become huge

El 10/12/2017 19:11, "Colin Finck"  escribió:

> Hi all,
>
> I have been looking into our HALs recently on the promise that it is a
> huge mess that needs fixing. Well, as a start I could imagine merging
> our 6 possible x86 HALs (Legacy, ACPI, APIC, ACPI+APIC, SMP, SMP+ACPI)
> into a single one, even if Windows ships individual ones. I see many
> advantages of that:
>
> * Less duplications and reduced mess: Right now, the APIC HAL hangs at
> HalpCalibrateStallExecution during boot, a function that has been fixed
> and universally implemented in all non-APIC HALs. The APIC HAL also
> duplicates HalpInitializePICs as HalpInitializeLegacyPIC.
> If you look at the SMP code, it didn't even receive the last build
> system changes and has conflicting implementations for APIC functions.
> A single x86 HAL would ensure that all possible configurations are
> maintained.
>
> * Future-proof: How is one going to implement newer features like x2APIC
> with a structure like that? Would it get another HAL, be integrated into
> the APIC HAL, or what?
> We wouldn't have such problems with a single x86 HAL.
>
> * Less setup work and testing: Currently, 1st stage setup detects the
> computer type and installs the appropriate HAL. As such, every
> additional HAL needs to be added to 1st stage setup code.
> 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.
>
> * Convenience: The same ReactOS installation could be used on several
> different x86 computers.
>
>
> So is this the way to go or do I miss something important?
>
>
> Best regards,
>
> 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