OpenBSD Journal

Developer blog: marco

Contributed by marco on from the acpi-non-status dept.

Over the last few days I haven't been able to do much due to the holiday season. Although Jordan and I had an interesting "can you please reboot the laptop again" day. He and I have been working on the ACPI code on and off over the last few weeks. It is kind of rough going but we are finally reaching a point where we will finally going to start making "visible" progress.

Due to Intel's crazy licensing of the ACPI reference code we can't import it into our tree so it has to be completely rewritten. I am happy about this, quite frankly, because the Intel code is completely unreadable. It can be the best code ever written but it gives me a headache. Also the ACPI spec blows other specs out of the water when it comes to unreadability. It's a classical spec in the sense that someone was bribed to go to Honolulu to "talk the spec over" and "reach a compromise". They don't even use spec language like shall and optional! It's deliberately vague so that everyone involved could agree. So Marco's engineering assessment is ACPI is a pile of camel pooh. All that said, my shiny new laptop needs it so it's time to suck it up and scratch the itch.

Thorsten Lockert kicked off most of the ACPI code in the tree a few months ago. Unfortunately he has been too busy with personal matters to continue to work on the code. He wrote all the code to load the tables into memory and created a basic driver framework. I need to credit Alexander Yurchenko as well for all his contributions! He has also worked off and on on this stuff but unfortunately he has also been too busy lately to join in on the fun. Jordan has written an AML (ACPI Machine Language) parser and interpreter (DSDT) so by now we can create the magical ACPI Name Space tree. I wrote the driver skeletons for the battery and AC (power supply) device and some other little things. The wait currently is on making the interpreter more robust since the drivers need to call into it to do their magic. When the interpreter works well enough you'll see suddenly stuff happen at an accelerated rate. Although let me warn folks beforehand that ACPI is a badly written spec (didn't I say that already?) and therefore misinterpreted at many hardware and software houses. I fully expect that we'll have to create tons and tons of quirks based on hardware models and versions before ACPI is going to be remotely useful. So don't send us email asking when it's done.

Since we really wanted to do something with our ACPI code Jordan and I made the power button work. So now when you press the power button or do a "halt -p" most machines should shutdown automatically (lots of help from Theo). The reason that not all hardware will do it is again due to the interpreter not being done enough. The ones that don't require AML should work. We tested this on amd64 and i386 boxes and it was pretty neat to see something happen for the first time :-)

Anyway, there is still tons of work to be done but this should bring you up to speed on where we are. I am sure I forgot to credit other folks so please forgive me beforehand.

(Comments are closed)

  1. By Anonymous Coward ( on

    And my crappy nx8220 with ACPI does not even boot OpenBSD, even not the latest snap.

    1. By Marco Peereboom ( on

      Snaps don't have ACPI enabled. So your crappy thingy is crappy in different crappy ways.

      1. By Anonymous Coward ( on

        that's true. I reported qhat I could to bugs, so I hope someone can help me.

  2. By grange ( on

    halt -p require aml, you need to know _S5_ package values. what openbsd acpi does now is just a hack.


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]