Contributed by dwc on from the Amalgamated-Coder-Punishement-Interface dept.
ACPI (Advanced Configuration and Power Interface) is the defacto standard to replace APM. As such, it's becoming increasingly important for full support on newer machines, as legacy support for APM is waning and ACPI-only machines become more common. Recently there was a flurry of commits related to ACPI, which got the attention of some people running -current with ACPI enabled kernels. In this interview we get a peek at what's been happening with ACPI and where it's headed.
The interviewed developers are:
Bob Beck (beck@)
Can Erkin Acar (canacar@)
Tobias Weingartner (toby@)
Other "attohackathon" developers include:
Gordon Willem Klok (gwk@)
Chris Kuethe (ckuethe@)
Mark Kettenis (kettenis@)
Jordan Hargrave (jordan@)
Read on for the interview…
dwc> It looks like a lot of exciting things went on with ACPI, and it's nice to see the commits. Having ACPI actually do something is pretty cool. Was this an organized hackathon?
beck> Kind of. Basically it was an "attohackathon" in Edmonton Alberta.
A few of us (Gordon, Toby, GWK, and Ckuethe) live here, and have varying degrees of success occasionally getting together to work through problems, even if it's just looking through code together.
A bunch of us have been annoyed over the crappy level of acpi support and Toby and GWK in particular were keen on doing something about it, but we needed some of the other people who work in the area.
Basically we invited Jordan and Can to come visit us for a weekend. I did some organizing, an paid for a hotel room, and wrote letters for visas. We mooched a hacking room that we were graciously allowed to use by the Department of Computing Science at the University of Alberta, and we all brought various "problem children" machines — everything from the Vaio UX, IBM X60's, the "Ferrari" Acer laptop (shudder) and the infamous "crash-o-tron" Intel box I bought ckuethe at one point for work.
canacar> Bob summarized this quite nicely. I was glad to be a part of this event, and it made me feel good to be finally addressing the issues and make ACPI support go forward.
toby> Organized yes. It was a bunch of us sitting around in Bob's basement telling each other that in order for ACPI to go forward we'd like to get Jordan and Can to Edmonton to work on it together. Bob made the arrangements happen. :)
dwc> When ACPI is enabled, what differences will users notice?
beck> Some things that used to work won't. Some laptops will be able to see sensors and halt -p, some will have thermal management for the first time… Some will have horrible things happen and crash and burn. YMMV — this is why acpi is not enabled by default yet.
canacar> Previously when acpi is enabled in GENERIC, only the parser would be activated so that we can parse and use the interrupt routing tables etc. We did not tell the hardware to actually enable the ACPI mode. Now, after the latest changes, we do.
When the hardware is taken to the ACPI mode, it starts to notify the OS to hardware related events, and expects to be responded properly, by the OS executing the proper AML (ACPI Machine Language) code. Some hardware may stop handling cooling/fans and leave thermal management up to the OS.
From a user's point of view, he will notice that: AC/battery status reporting should work, and so is halt -p and/or the power button.
On the negative side, there is more code running, and users may encounter panics and changes in system behaviour. I would advise users who enable acpi to monitor the system and make sure it is not overheating or having interrupt storms.
toby> I'm hoping that they'll notice things just working better. Unfortunately, that will likely not be the case yet. Many machines will work better with ACPI enabled (especially newer machines), but some will hit on new bugs that enabling ACPI will uncover. The good thing will be that these people can report the bugs [see sendbug(1)] so they can be fixed.
dwc> Are some methods for the OS to identify itself to ACPI better than others, and what are the different results?
beck> You can have different results depending on how you identify yourself — it's not clear which ones will be "better" or "worse" — Identifying yourself as, let's say "Windows NT" may mean the bios will set up things "sanely" to let stuff work with minimal ACPI interference, or it may simply disable devices, or it may try to "work around" OS bugs in the bios. At the moment I don't think we've really come to a firm landing on what we should identify ourselves as, and it isn't always clear there is any one right answer yet. Oh, and there's also more than one way to identify yourself too, just to make things a little more complex.
canacar> All operations and 'functions' in ACPI is written in AML, which is a java-like bytecode, and sometimes too complex. Most AML code has work arounds for different operating system versions (mostly related to ones from Redmond). These AML paths are the most used/tested ones, so should be safer to use.
toby> There are basically two ways for the OS and ACPI to identify each other, plus an extension to the second way. Currently we do our best to use AML code that should implement full ACPI control of the machine.
dwc> Is there new support for significant devices, or perhaps classes of device? How about i386 vs. amd64?
beck> Well, not so much "support for device" as much as "things will work better."
The holy grail is still a working resume (Theo will yell at me for saying that.) That is, the ability to suspend AND RESUME afterwards. But that may take quite a while yet, and frankly, we're not looking at it until some of the other more basic stability and functionality problems are licked.
canacar> Right now you should see thermal zone stuff (temperature sensors, etc.), battery and AC status reporting. You can also enable acpicpu for setting cpu speed through ACPI.
We have to make sure we do not break old devices. If a machine has a working APM we want to keep it working (as most can suspend). Most likely amd64 will get ACPI enabled by default before i386, but it will not be soon.
toby> The reality is that most of this code has been in the tree for some time now, but has not been enabled, or required a full rebuild of a kernel to get it 100% enabled. With the way things are now, simply enabling (using boot -c for example) the acpi device will enable most of the acpi devices.
One of the good things is that some laptops are already being fixed by using the AML interpreter we have. For example, gwk's x60 is much more stable having all the ACPI devices enabled. The wpi(4) works better, halt(8) works correctly with the -p flag, and I'm sure there were other things that worked better with it as well.
dwc> What are the remaining challenges for ACPI support? Does it look like we'll see ACPI enabled by default soon?
beck> The biggest challenges are
- Stability (particularly on machines will really crappy AML)
- Not interfering with what already works. None of us who have working machines without acpi (either by accident or because APM works) want that to be screwed up by ACPI.
So, please don't view this as an end, but rather (put your churchill hat on) "the end of the beginning" — hopefully with more people using it and sending in useful dmesg and bug reports more progress can be made.
canacar> The best part of this hackathon is that we are now getting real bug reports and are able to fix things now that this code is being tested. I think we got more reports, in the two days after we enabled ACPI in generic then we did in the past two years.
toby> This is a tougher call. We know there are still issues with the current code, and are working hard to try and address those. At the current time it is basically tossing as many different and varied ACPI/AML bios at the current code to stress test all the different code paths. For each bug that is fixed, a whole range of new machines will begin to work.
Thanks to the developers for the great work, and special thanks to Bob Beck for getting everyone together.
(Comments are closed)