Intel wrote a generic ACPI implementation for Unix-ish systems, which is being used as the basis for ACPI support in Linux (see here). To get around the "buggy firmware" problem, they're maintaining a "blacklist" and a "whitelist", and provide improved/corrected DSDT's for some systems. The ACPI4Linux project has been working on it in conjunction with Intel for 4 or 5 years now and (IIRC) do have working ACPI support, but (IMHO) don't have good integration with the rest of the OS.smiddy wrote:Well, when I said I'd stop reading, I didn't. There is a lot of complexity there, I agree. And too, if you want to use the tools from Intel, they make them specifically for Windows mainly. I'm not sure there is an entire connection there, in other owrds, that due to Windows functionality with ACPI, then your OS is bound by that (I'd have to research that more). I have read the fears out there about the potential bugs and the unknowns. I think it is a natural human, for lack of another work, emotion to fear the unknown and put trust into something we don't control.
If the goal of ACPI was to make configuration and power management easier, then I'm thinking it's failed to achieve this goal.
OS/2 was first released in 1987, and pre-dates ACPI by around 8 years.smiddy wrote:I can't recall where I read it, it may have been one of the OS Design books out there, that OS/2 did everything to start up, in the early days, I can't say for now, by doing probes of (hopeful) devices. I think that may have been pre-PCI. It covered PnP and I think was tightly woven in the 80286 protected mode.
I wouldn't intentionally limit the design to anything. The implementation is a different thing though, which must be limited in the initial stages, but should become less limited over time. Resources used by PCI devices and ISA devices that support ISA Plug & Play aren't too hard to detect, and common devices (PIT, CMOS, PIC, DMA, serial, parallel, PS/2, floppy) aren't hard to manually probe. Motherboard resources (chipset specific I/O ports, etc), and older ISA cards are a larger problem.smiddy wrote:Could you limit your design to PCI only systems? Or would you want to? your construct has been to use a networked systems design, so potentially you might use another machines resources for one machine, so potentially you only need rudementary designed system with a NIC (assuming Ethernet interface) on some machines, but others might have everything needed in order to compute what is needed, say for instance floating point math at the 128-bit level, which for an 8086/88 would be a tedious task of emulation, but shipping the computational needs off to another computer capable of doing it, then shipping it back for inclusion would be a great thing. Is this right? Interesting!
For me this means a generic "device manager" module which loads an (optional) "chipset driver" module, and then does an ISA Plug & Play scan (if necessary), ISA device probing (if necessary), then PCI bus scan (if necessary). The chipset driver module could be a chipset specific driver or possibly a "generic ACPI driver". In a similar way, the device manager itself could be replaced by a custom module (e.g. something that uses a static table with no actual detection for an embedded system or game machine with unchangeable hardware).
Cheers,
Brendan
