Abstract

This document outlines the overall design of the kernel, as it relates to Chromium OS.

Background

Chromium OS is based on the Linux kernel, initially from version 2.6.32. More specifically, we intend to take the Ubuntu kernel as a starting point, adding other changes that are necessary for the features and stability we desire.

Source code

Git repository

The Chromium OS Linux kernel will be stored in a Git repository, hosted on an externally accessible website. All platforms will build from one single kernel source tree (though there will be multiple binary images).  

If necessary, we will create short-term private branches for specific vendor projects that involve pre-production hardware. These branches will be merged back into the main kernel as soon as possible, using one code review per CL so that all code in our master branch is either from upstream or code reviewed. The intent of these private branches is to enable code review and project status monitoring of code that cannot be publicly released yet, due to NDA. The intent is specifically not to use these branches to keep changes that are shipping to customers.

Any code submitted should be done as one Git commit per logical change, with a good description. (See Documentation/SubmittingPatches in the kernel tree.) We may create temporary public branches for the purpose of working together on code review and integration.

Licensing

All Linux kernel code, from Google and from partners, must be released under GPLv2 and must be released under the DCO (documented certificate of ownership) as a signoff of ownership. Each commit will contain the signoff of the code author/committer and the ACK of the patch approver. Code should be submitted under the Chromium contributor license agreement.

Changelog entries

Here's an example of a changelog entry:

CHROMIUM: bibble: a patch to fix everything

Bug: 12345

This patch fixes bug 12345 by checking for a NULL pointer before dereferencing ops->thingy

Signed-off-by: Author <author@example.net>
Signed-off-by: Committer <committer@example.net>
Acked-by: Approver <approver@example.net>

All kernel code (including backports from upstream) contributed by Google or partners will include a classification tag in the first line of the commit log. The classification will be useful when the maintainer needs to rebase to a newer kernel; the tag is also needed for proper attribution. The tag is in ALL_CAPS_UNDERSCORE, is followed by a colon, and is at the beginning of the first line. The first line from each commit should be a summary.

Code contributed by the Chromium community will use the tag CHROMIUM. For example:

CHROMIUM: bibble: a patch to fix everything

Code backported from upstream (Linus's tree) will use the tag UPSTREAM. For example:

UPSTREAM: bibble: a patch to fix everything

Code backported from an upstream maintainer tree will use two tags. For example:


Code ported from a Linux distribution tree or other non-upstream tree will also use an appropriate tag. For example:

or

MOBLIN: bibble: a patch to fix everything

Upgrades

The kernel will be upgraded to a new version as soon as practicable after a new version of the Ubuntu kernel is released. We will do this via a Git rebase, this means we'll keep clean versions of our patches floated on top of the latest tree. In practice, this will happen approximately every 6 months, and approximately every 2 kernel versions from upstream. Other, smaller updates will be done on a continuous basis.

After a rebase, subsequent changes from the Ubuntu kernel will have to be cherry-picked and submitted as independent changes that go through proper code review.

All third-party vendors are expected to supply updated versions of their code against every new mainline kernel version (for example, at 2.6.31, 2.6.32, 2.6.33, and so on) within 30 days of its release, if the code is not already upstream.

Supported and unsupported features

Kernel modules and initial RAM disks

We will support kernel modules, though this feature may be removed at some point in the future. We will not support modules built outside of the main kernel tree.

We will not support initial RAM disks (initrd).

Architectures

Support for i386, ARM (v7 or greater) and x86_64 is planned

The tradeoff for using 64 bits is additional power consumption and memory usage, in return for greater performance.

Swap

We do not plan to support swap in our initial release, but will conduct a further feasibility investigation to review this. We are concerned about the effect of swap on:

• SSD write cycle lifetime
• maximum latency
  

We realize that not having swap will limit how many tabs a user can keep open and the amount of anonymous memory a process can allocate. Aggregate size of anonymous memory in the system will be limited to the size of RAM. We may revisit this decision in future releases.

Files

Device drivers

If device drivers are not backports from upstream, they should be placed under chromeos/drivers.

Configuration files

On i386, and x86_64, we will keep two kernel config files per architecture: one smaller one to support the official Google Chrome OS devices, and a larger file to enable broader support for Chromium OS. On ARM, each SOC vendor will need its own configuration file.

To make this more maintainable, config files will be assembled from sections to avoid repeated data.

References

http://wiki.ubuntu.com/KernelTeam/Specs/JauntyKernelTreeManagement
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches