Sorry, you need to enable JavaScript to visit this website.


This project enables Linux to take advantage of platforms supporting Advanced Configuration & Power Interface -- virtually all high-volume i386, x86_64, and ia64 systems since 1999. ACPI, known as a Hardware Abstraction Layer (HAL) in embedded computing, is an abstraction layer between the operating system, platform firmware and hardware. This allows the OS and the platform to evolve independently. The core of the Linux ACPI implementation comes from ACPICA (ACPI Component Architecture). ACPICA includes an ACPI Machine Language (AML) interpreter that is resident in the Linux kernel. Several other operating systems use the same ACPICA core interpreter, including BSD and OpenSolaris. ACPICA also comes with a simulator, test suites, and a compiler, to translate ACPI Source Language (ASL) into AML.

Read and follow Documentation/SubmittingPatches in the Linux Kernel source tree.

Proposed patches to the Linux ACPI kernel sub-system should be e-mailed to for review, comment, and testing by the community. Patches that touch code outside drivers/acpi/ must also cc:

It is important to describe your expectations of the patch in the e-mail. If it is an experiment, or a debug patch, please say so. If it works just for you, but you think it is ready to go upstream, please say so. If it has been tested by others and Acked-by: others, please note that also. When you think it is ready to go upstream, be sure to add to the "to: list" and include "please apply" in the message.

Note that Len prefers patches in plain text, as that is what reviewers prefer to read. But if you need to use attachments, to prevent your mail client from garbling plain text, he can handle those, too.

Len also takes patches directly from bugzilla entries. Indeed, he tries to give priority to bugzilla fixes because bugzilla does such a good job of remembering the details of the issue, and the people involved have taken the trouble to carefully enter the data in bugzilla.

If you send a patch as an attachment, or attach it to bugzilla, it is helpful if you format the patch according to SubmittingPatches, that is, include a From:, a Subject:, and check-in comments before the patch body, to make it look enough like an e-mail message that git-am can parse it without manual editing.