Kernel Dev

Very rough notes on kernel dev. Jotted down from the Kernel Dev 101 course from the Linux Foundation.

Linus Torvalds releases a new kernel and opens a 2-week merge window. During this merge window, he pulls code for the next release from subsystem maintainers. Subsystem maintainers send signed git pull requests to Linus either during the merge window or before. All major new development is added to the kernel during the merge window.10,000+ change sets (patches) get pulled into Linus’s tree during these 2 weeks, at the end of which he releases the first release candidate, known as rc1.

At this point, the release cycle moves into a bug fixes-only mode, with a series of release candidate (rc) releases from Linus. One week after rc1 is released, rc2 comes out; rc3 comes out a week after, and so on, until all major bug fixes and regressions (if any) are resolved.

The new cycle begins with a 3-week quiet period, which starts a week before the release, and continues through the 2-week merge window. Maintainers and key contributors are busy getting their trees ready to send pull requests to Linus. Please note that the quiet period isn’t formalized, and each sub-system might handle it differently. This period isn’t well advertised, and new developers might see a slow response from the community.

Greg Kroah Hartman -stable branch

Acked -By and other tags exist v16 implies patch has gone through 16 revisions Git Email Configuration

Configuring git-email to send patches is easy using the sendemail configuration option, once you have your smtp server configuration. There is a wealth of online resources for obtaining information on configuring git sendemail to send patches. You can see an example for gmail below.

Once you place the above configuration in your .gitconfig file, running git send-email mypatch.patch is all you have to do to send patches; mypatch.patch is generated by the git format-patch command. Dont send patches as html attachments always bottom post

cd /linux_work
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux_mainline
cd linux_mainline; ls -h

git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux_stable
cd linux_stable
git branch -a | grep linux-5
    remotes/origin/linux-5.12.y
    remotes/origin/linux-5.11.y
    remotes/origin/linux-5.10.y

​git checkout linux-5.12.y

mokutil –sb-state

Automated build bots and Continuous Integration (CI) test rings run tests on various kernel repositories. Maintainers and developers can request their repositories to be added to the linux-next integration tree and the 0-day build bot. The 0-day build bot can pull in patches and run build tests on several configurations and architectures. It is helpful in finding compile errors and warnings that might show up on other architectures that developers might not have access to.

Continuous Integration (CI) rings are test farms that host several platforms and run boot tests and Kernel Selftests on stable, linux-next, and mainline trees. All these tests are run on real hardware, as well as Qemu environments, covering a wide range of architectures and configurations. Please take a look at the following resources for the latest status on kernel releases:​

Kernel CI Dashboard
0-Day - Boot and Performance issues
0-Day - Build issues
Linaro QA.
Buildbot.