(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&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 < > 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 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 >>> >> >> >> _______________________________________________ >> 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
