Sir Richard 2031c565df [NTOS]: Check registry for our CardList, check if the PCI hardware matches any entry in there that specifies it has full/extended address decoding, and write the registry flag for it. ... svn path=/trunk/; revision=47660		2010-06-07 15:09:44 +00:00
..
bus	[HAL]: Add missing PCI Bus Handler support functions, used on non-ACPI systems (ISA-PCI support and such).	2010-06-07 03:19:20 +00:00
.gitignore	[HALACPI]: Add project, right now it just builds the normal HAL. The idea is to split the generic HAL into legacy (x86 only) and ACPI (x86+ACPI, or x64). Bus handling, reboot/shutdown, PnP, power management (sleep/resume/hibernate), timer, environment variable, debugging, and initialization code is expected to differ between legacy and ACPI, if not more.	2010-03-29 21:35:31 +00:00
bussupp.c	[NTOS]: Check registry for our CardList, check if the PCI hardware matches any entry in there that specifies it has full/extended address decoding, and write the registry flag for it.	2010-06-07 15:09:44 +00:00
halpcat.c	[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).	2010-06-07 01:09:41 +00:00