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

Feedback

Your feedback is important to keep improving our website and offer you a more reliable experience.

Linux*-ACPI

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.

How do Linux ACPI Patches Get Into the Upstream Kernel?

  1. The community develops, reviews, and tests patches.
  2. Len Brown, the Linux ACPI maintainer, checks them into the ACPI git tree, and pulls them onto the test branch. (see Get Latest Source Code)
  3. Andrew Morton consolidates the entire ACPI test branch into a single git-acpi.patch in his "mm" testing release: http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
  4. Len moves mature patches from the ACPI test branch to the ACPI release branch, and sends a "pull request", asking Linus Torvalds to pull them into his upstream kernel.
  5. Distributors periodically re-base their products onto Linus' upstream kernel.

How Linux ACPI fits into the Linux Kernel Release cycle

Linus releases a kernel about every 8 to 12 weeks.

After a kernel has been released, critical patches are integrated by the stable team into a stable tree, while Linus moves on to the next release.

The next release begins with a 2-week "merge window". Linus requires all patches that change features to be available to him on the first day of the merge window, so he can order integration logically.

After the 2-week merge window is closed, all future patches to that release should be bug-fixes only, with priority given to fixing regressions.

What this means is that if you want to add a feature or a driver, you need to get it into Len's tree well before Linus' kernel release, so that:

  1. Len can get it through the ACPI test tree.
  2. Andrew can get it through the mm tree.
  3. Linus can pick it up on the first day of the merge window for the next release.

If you miss the merge window, it will be up to 3 months before the next opportunity.

But fixes to regressions are welcome at any time. However, if the fix touches a lot of code and has high risk, sometimes a simpler, less beautiful fix (okay, a low-risk hack) is needed for the current release. This same hack might be appropriate for the .stable release, as well. The hack can be replaced with a more complete fix in the next release.

Project: