Jeg har udskudt det længe, næsten 10 år, for jeg vidste at jeg ville blive sur når jeg gjorde det, men nu har jeg læst ACPI specifikationen.
Jeg kan desværre ikke give jer en link, for organisationen bag den er ikke på nettet lige nu, men kig på "www.acpi.info" hvis de kommer online igen.
Oprindeligt handlede ACPI om power-management, hvordan man kunne suspend'e sin laptop og få den i live igen.
Af årsager der kun kan beskrives som hysterisk tragiske, implementerede ACPI folkene deres helt eget specifikationssprog med sit eget underlige byte-code format, til trods for at det vitterligt havde fyldt mindre på alle leder og kanter hvis de havde brugt f.eks Tcl eller et subset af PERL.
Det næste der skete var at PCI bussernes interrupt routing blev noget rod, "fire interrupts er nok til hvem som helst" som en eller anden starut hos Intel formodentlig sagde, men han tænkte ikke på at med 20 PCI devices kom man over de 12 interrupts som den originale i8259 controller havde ledige og at man derefter manglede information om, hvordan interrupt routing foregik i systemet.
Og så var tendensen klar: Hver gang nogen dummede sig et eller andet sted, "så fixer vi det bare i ACPI".
Magiske timing konstanter for ATA/IDE controllere ? Lad ACPI klare det.
&c, &c, &c.
Ideen i et "Hardware Adaptation Layer", et "HAL", er god nok, det gør det nemmere for både hardware designeren og operativsystem koderen at interface over en intelligent specificeret kontrakt.
Men ACPI er netop ikke et HAL, det er outsourcing af en del af operativsystemet til BIOS-kodere der ikke aner hvad et operativsystem kan, skal eller må.
Beviset på hvor galt det er gået, er at de fleste ACPI-BIOS'er, er nødt til at vide hvilket operativsystem der kører, istedet for at operativsystemet gør hvad der skal gøres af underlige tiltag:
| OperationRegion (OSTY, SystemMemory, 0x7F650EF6, 0x00000001)
| Field (OSTY, AnyAcc, NoLock, Preserve) { TPOS, 8 }
| [...]
| If (CondRefOf (_OSI, Local0)) {
| If (_OSI ("Windows 2006")) {
| Store (0x40, ^OSTB)
| Store (0x40, ^TPOS)
| } Else If (_OSI ("Windows 2001.1")) {
| Store (0x20, ^OSTB)
| Store (0x20, ^TPOS)
| } Else If (_OSI ("Windows 2001 SP1")) {
| Store (0x10, ^OSTB)
| Store (0x10, ^TPOS)
| } Else If (_OSI ("Windows 2001")) {
| Store (0x08, ^OSTB)
| Store (0x08, ^TPOS)
| } Else {
| Store (0x00, ^OSTB)
| Store (0x00, ^TPOS)
Der er ingen grund til at undre sig over at hverken Linux, OS/2 eller FreeBSD er nævnt, vi har forklaringen direkte fra Hans Billhed selv:
Citat:
One thing I find myself wondering about is whether we shouldn't try and make the "ACPI" extensions somehow Windows specific. [...] Maybe we could define the APIs so that they work well with NT and not the others even if they are open. Or maybe we could patent something related to this.
Den gang jeg gik i gymnaset var humanisterne meget bange for at "computerne ville tage magten".
Man kunne som operativsystemdesigner godt få den mistanke, at det er et par gamle syrede Cand. Mag'er der som dobbeltagenter har fostret ACPI ideen.
Det kommer ihvertfald til at tage langt tid før fremskridtet går for vidt med ACPI som handicap.
phk
PS: Jeg påkalder mig PTO's lov: ikke et ord om OOXML i debatten herunder.
Noget af det mere komiske er endda at selvom Microsoft formåede at få ACPI til at favorisere deres styresystem, er det stadig ikke lykkedes dem at implementere sleep og hibernation på en måde som ikke gør deres styresystem ustabilt :)
Næeh, hvis noget skal gøres ordentligt, så overlad det til HKH Steve Jobs.
Hej Poul-Henning,
Jeg mindes noget med at PPC bruger OpenFirmware.
De er HW vidt forskellige, men samme OS.
Så er det ikke på tide at kigge i den retning. Så vidt jeg ved er det noget i den stil at de nyere Macs virker enda med Intel HW.
Men ja, open specification standarder er en rar ting.
Uden at have læst om ACPI, så har jeg den fornemmelse at man ikke kan lave en standard metode til at arbejde med ACPI på hvilkensom helst HW fra det samme OS. Da der har været for mange kokke om tilberedningen.
For at lede folket i en retning af hvordan man kan adskille drivere fra forskelligelag, GEOM implementationen i FreeBSD, dette er skrevet af PHK.
Læse materiale kan bla. findes her:
http://phk.freebsd.dk/pubs/
Coreboot (fmr. Linux BIOS) anyone?
http://www.coreboot.org
Ja, hvis interrupt status registeret tjekkes, så man ser om interruptet er til en selv, og hvis man kæder alle interrupts på det pågældende hardware interrupt, så er éet interrupt nok. Men med netop 4, undgås at kæden bliver så lang, at den hopper af. Samtidigt er 4 nok til, at supportere de prioriteter, som eksempelvis windows supporterer.
Der er rigtigt meget indenfor software og hardware området, der minder om "administratum", og "beslutninger", der har til formåle at give fuld beskæftigelse. ACPI er ingen undtagelse.
Det virker særdeles vittigt, at indføre et programmeringssprog, for at reelt indføre en "wait" indstruktion, eller evt. at kunne sætte CPU'ens hastighed ned, som IBM gjorde før ACPI.
