ACPI and JNode

It is true point coming to us that ignoring ACPI is not a Option for JNode at this moment.

Thanks
Tanmoy

Hi

I've read a little bit about ACPI and seems to be a nice toy . It is used by big players Microsoft , Linux , Intel , HP etc.

I am not an ACPI expert so I've tried to find on Google some opinions and i found a very interesting opinion in the Linux garden :

I will quote here

"Concerns about ACPI. The Advanced Configuration and Power Interface is the industry's current answer to power management. It is supposed to fix all of the problems with the older APM specification, and provide a great many new features as well. And, in fact, ACPI does promise some nice things. Kernel hackers have always been a bit concerned about ACPI, however, and the level of that concern seems to be rising as the implementation (led by Intel's Andy Grover) increases in functionality.

The concern arises from the complexity of both the ACPI specification and its implementation. There is no doubt that the specification is intense - it is available from the ACPI web site as a 450-page PDF file. The real problem, however, is not the size of the specification itself, but in the way it expects to handle device control.

The ACPI specification defines a language called AML ("ACPI Machine Language"), and an (allegedly) human-readable version called ASL ("ACPI Source Language"). An example from the specification:

Device(EC0) {
Name(REGC,Ones)
Method(_REG,2) {
If (Lequal(Arg0, 3)) {
Store(Arg1, REGC)
}
}
Method(ECAV,0) {
If (Lequal(REGC,Ones)) {
If (LgreaterEqual(_REV,2)) {
Return(One)
}
Else {
Return(Zero)
}
}
Return(REGC)
}
}

Think of it as a sort of verbose C++ subset with lots of capital letters and no semicolons and that's probably all you really need to know.

BIOS writers are supposed to provide AML code (with the motherboard BIOS or the device itself) which helps each device implement parts of the ACPI specification. Systems implementing ACPI are required to run this code in a privileged mode when required. In other words, to implement ACPI, the Linux kernel must:

* Run arbitrary, binary-only code from outsiders...
* ...which implements a huge, complex specification...
* ...in kernel mode...
* ...with a bulky interpreter (built into the kernel)...
* ...hoping that there are no bugs or misfeatures in this code...
* ...even though BIOS code has been the source of endless headaches for years.

Once you look at it that way, it's not too surprising that people are wondering about the whole thing. As Alan Cox put it:

The fact that it takes more code to parse and interpret ACPI than it does to route traffic on the internet backbones should be a hint something is badly wrong either in ACPI the spec, ACPI the implementation or both

Beyond standard-variety bugs, ACPI code could be a point of entry for surveillance software, "content management" code, and no end of other, malign functions. And it all runs in kernel mode with full access to the system. People don't trust it, and with good reason.

Given all that, one could find it tempting to do without ACPI altogether, and that is what most Linux systems do now. Systems are starting to appear, however, which do not implement the old APM standard, meaning that ACPI must be used for power management tasks. And power management is important; anybody running a large server farm in California would certainly be pleased with better control over power consumption.

More importantly, however, ACPI is also becoming the means for hardware discovery and configuration in general. There will likely come a time, before too long, when an understanding of ACPI will be necessary simply to get a system up and running, even if power management is of no concern. Itanium systems, already, can not run without ACPI. Ignoring ACPI is not an option.

All of this has led some hackers to propose a new approach to ACPI. Instead of implementing the whole specification, interpreter and all, why not put together a minimal subsystem which extracts the needed information from the ACPI tables and ignores the rest? There would be some work involved in this approach; there would certainly be AML control routines which would have to be disassembled and reimplemented. But the result could be a simpler, smaller system that does not need to run external, binary code in order to function.

Of course, the ACPI team, which has put years of effort into the current implementation, sees things a little differently. To them, the full ACPI interpreter is the proper way to deal with changes in the hardware industry, and the concerns being raised are overblown. ACPI detractors should, they say, at least demonstrate some real problems before throwing away that much work.

It may take years to resolve how Linux will deal with ACPI in any definitive way. The possibility of a dual implementation, where both the minimal and the complete ACPI subsystems are available, is real. "
"

The link is here Link

So i think to implement all the spec it is a little to hard but i think a modern OS must support this spec . I think it is better to support ACPI

Best regards
Andrei Dore