Примечание: Статья в процессе написания.

Краткое описание процесса разработки ядра 🐧

Разработка ядра Linux происходит публично согласно kernel development process. Подробное описание https://docs.kernel.org/process/development-process.html

Код для ядра должен быть совместим с лицензией GPL-2.0 (например, совместим код под лицензией BSD-3-Clause, см. список совместимых лицензий в исходном коде ядра в каталоге LICENSES). По лицензионным причинам код от анонимов/псевдонимов не принимается. Весь код (каждый коммит) "подписывается" (тегом signed-off-by) что означает заявление о соответствии кода свободной лицензии.

Все комментарии, описания пишутся и обсуждения ведутся только на английском языке.

Подготовка патчей

Индивидуальные разработчики в соответствии со своими задачами вносят изменения в код ядра на своей копии репозитория mainline (torvalds/linux) и как правило на основе последнего (пре)релиза. Происходит цикл - разработка, локальное тестирование. Git коммиты (будущие патчи) разделяются на смысловые части, для каждой дается описание в commit message. Код оформляется в соответствии со стилем ядра (проверяется скриптом scripts/checkpatch.pl). Обязательно, каждый добавляемый коммит не должен ломать сборку ядра (чтоб не помешать в будущем git bisect).
Перед отправкой формируется patch set (git format-patch), версионируется и добавляется changelog если это не первая версия, добавляется cover letter [PATCH 0/N] если патчей больше одного.
Затем патчи публикуют — отсылают по email в списки рассылки затрагиваемых подсистем (git send-email). Актуальные списки рассылок указаны в файле MAINTAINERS. Если отдельного списка нет или дополнительно к списку нужной подсистемы ставится копия в общий список lkml. Также ставится копия на личные адреса мейнтейнеров нужных подсистем и, иногда, на предыдущих разработчиков застрагиваемых файлов или разработчиков чей код меняется, ревьюверов. Для определения списка адресатов есть скрипт scripts/get_maintainer.pl.
Опубликованные в списках рассылки патчи попадают на сайты patchwork (выделяет только патчи и отслеживает статус reviewed/acked/tested) и lore (сохраняет все письма с доступом по message-id).

Прием патчей апстримом

После публикации патчей дается неопределенное время, чтоб другие разработчики ядра сделали code review. (Если никто долго не отвечает можно послать т.н. ping.)
Разработчики отвечают в список рассылки комментируя код в цитировании (inline replying), если замечаний нет, то указывается тэг reviewed-by.
Мейнтейнеры затрагиваемых подсистем присылают одобрение в виде тэга acked-by, это значит, что они разрешают изменение (и прием патчсета затрагивающего их подсистему в чужое дерево).
Если кто-то тестировал работоспособность патчей, то он присылает тэг tested-by.
— Все присылаемые в ходе review тэги попадут в итоговый коммит.
Если были замечания, то разработчик их исправляет повторяя цикл разработки и публикует версию n+1 (указывая, что это новая версия [PATCH v2] и добавляя changelog).
Если замечаний нет мейнтейнер (и есть успешные reviewed-by или acked-by) подсистемы куда прислан полный патчсет принимает его в свое git дерево и пишет об этом в ответ на письмо с отдельным патчем или на cover letter для patch set.

Прохождение патча в апстриме

Попадание в mainline

Цикл разработки одного релиза mainline ядра длится около 2 месяцев. Первые 2 недели из них называются merge window, во время которых Линус Торвальдс принимает новые фичи в ядро, а в остальное время - исправления к тому, что уже принято, для стабилизации следующего релиза. После окончания merge window каждую неделю выпускается релиз-кандидат (в основном репозитории Линуса).

Мейнтейнер, принявший патчи, в зависимости от их характера, решает, когда отправить их дальше — в текущем цикле разработки ядра или в следующем. Например, если это новый функционал, а merge window уже прошло, то патч откладывается до следующего цикла. В зависимости от этого он принимает (пушит) их в один из своих git-репозиториев. Если он планирует послать их в merge window следующего цикла, то это может быть не основной репозиторий этой подсистемы.

Попадание в stable

После релиза mainline ядра stable team (во главе с Грегом КХ) выбирает коммиты из mainline с фиксами багов и backport'ит их в stable/longterm ядра. Важно, что выбираемые коммиты, за редким исключением, должны уже быть приняты в mainline — а значит они уже прошли процессы review и тестирования для mainline. Основной способ выбора коммитов — это AUTOSEL process.

Релизы стабильных ядер происходят примерно каждую неделю. Патчи для новых stable релизов пушатся в репозиторий stable-rc и постятся в список рассылки stable с анонсом где сообществу дается время на их review и тестирование. Протестировавшие отвечают на анонс с описанием проведенного ими тестирования и тегом tested-by.

Если не выявлено проблем коммиты пушатся в репозиторий stable, ставится релиз тег и делается анонс.

Выступления и презентации

Linux Kernel Security Demystified [2023]

Kernel Recipes 2023, Greg Kroah-Hartman, Kernel Maintainer & Fellow, The Linux Foundation

There is a lot of misunderstanding about how the Linux kernel deals with security vulnerabilities. This talk will go into how the Linux kernel security team works, how changes are propagated out to the public, and how users must take advantage of these changes in order to have a secure system.

A Rolling Stable Kernel Model [2021]

Open Source Summit + Embedded Linux Conference + OSPOCon 2021, Sasha Levin, Google

While version numbers don't truly matter, the kernel's versioning scheme suggests they do. As a result, we often see a disconnect between how kernel developers want to see the kernel maintained, versus how the kernel ends up being maintained. This talk will go over a brief history of the kernel's versioning schemes, will try to demonstrate why it does fit with the current approach to keeping the kernel up to date, and will propose an alternative method to maintaining a rolling stable kernel tree which ignores changes in version numbers and makes it easier for users to make sure they have all the fixes they need.

Safeguards in the Stable Kernel Process [2020]

Open Source Summit 2020, Sasha Levin, Microsoft

There is a common misconception that while Linus's tree is heavily tested and validated, the Stable and LTS trees aren't reviewed or tested at all. This talk aims to change this misconception. In reality, Stable trees are not only heavily tested, but the testing they are being subjected to is much more similar to "real world" workloads that the kernel will have to endure once it's released. We will go over every step a patch goes from the point it's sent to the mailing list, to after it was included in a stable tree, highlighting the process which makes it very difficult to introduce bugs into the Stable trees.

Kernel/process

Содержание