Как принять участие в разработке ядра Linux

1: РУКОВОДСТВО ПО ПРОЦЕССУ РАЗРАБОТКИ ЯДРА

Цель данного документа — помочь разработчикам (и их руководителям) найти общий язык с сообществом разработчиков ядра. Это попытка описать то, как работает это сообщество, в особенности для тех, кто не знаком с разработкой ядра Linux (или разработкой свободного програмного обеспечения в целом). Несмотря на то, что в документе присутствуют некоторые технические детали, здесь в большей степени отражен сам процесс разработки, который не требует глубоких познаний в области системного программирования.

1.1: ОБЗОР

Первый раздел охватывает процесс разработки ядра и подводные камни, с которыми могут столкнуться разработчики и их работодатели. Существует множество причин, почему код ядра должен быть интегрирован в официальное("mainline") ядро, такие как доступность для пользователей, поддержка сообществом в разных формах и возможность влиять на направление развития ядра. Код, добавляемый в ядро Linux должен быть доступен по лицензии, совместимой с GPL.

Раздел 2 освещает процесс разработки, цикл релиза ядра и механизм работы периода принятия патчей (окна принятия). Описаны различные фазы в разработке патчей, ревью и цикл слияния. Обсуждаются инструменты и списки рассылки. Разработчикам, желающим принять участие в разработке ядра, в качестве начальной практики советуют отслеживать и устранять ошибки.

Раздел 3 описывает планирование проекта на ранней стадии, с акцентом на скорейшем привлечении сообщества разработчиков.

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

Раздел 5 рассказывает о процессе публикации патчей для рецензирования. Чтобы патчи были приняты сообществом разработчиков всерьёз, они должны быть правильно отформатированы и описаны, и должны быть отправлены в соответствующее место. Советы в данной секции должны помочь обеспечить наилучший возможный приём вашей работе.

Раздел 6 объясняет, что происходит после публикации патчей; на этом этапе работа еще далека от завершения. Работа с рецензентами - ключевая стадия процесса разработки; этот раздел предлагает набор советов как избежать проблем на этом важном этапе. Разработчиков предупреждают, что лучше не считать работу законченной, когда патч залит в основное ядро.

Раздел 7 описывает пару "продвинутых" тем: управление патчами с помощью git и рецензирование патчей, опубликованных другими.

Раздел 8 завершает документ ссылками на ресурсы для дополнительной информации по разработке ядра.

1.2: О ЧЁМ ЭТОТ ДОКУМЕНТ

Ядро Linux, с более чем 6 миллионами строк кода и более 1000 активных разработчиков, является одним из самых больших и самых активных среди существующих программных проектов. Со времени его скромного начала в 1991 это ядро развилось в оптимальный компонент операционной системы, которая запускается на карманных цифровых музыкальных плеерах, настольных компьютерах, крупнейших из существующих суперкомпьютеров, и различных промежуточных видах систем. Это надежное, эффективное и расширяемое решение для почти любой ситуации.

С развитием Linux возросло число разработчиков (и компаний), желающих участвовать в его разработке. Производители железа хотят быть уверенными, что Linux достойно поддерживает их продукт, делая его привлекательным для Linux-пользователей. Производители встроенных систем, использующие Linux как компонент в их конечном продукте, хотят чтобы Linux мог выполнять множество различных задач и максимально им подходил. У компаний-распространителей и других производителей, основывающих свои продукты на Linux, есть прямой интерес в возможностях, производительности и надёжности ядра Linux. И конечные пользователи так же всегда будут хотеть подстроить Linux под себя, чтобы он лучше удовлетворял их потребностям.

Одной из самых неотразимых особенностей Linux является его доступность для этих разработчиков; при наличии необходимых навыков любой может улучшить Linux и повлиять на направление его разработки. Коммерческие продукты не могут предоставить подобную открытость, которая является характеристикой процесса открытого программного обеспечения. Но, пожалуй, ядро даже более открыто, чем большинство других проектов открытых программ. Типичный трёхмесячный цикл разработки может включать более 1000 разработчиков, работающих на более 100 разных компаний (или ни на кого не работающих).

Работать с сообществом разработчиков ядра не слишком трудно. Но, несмотря на это, многие потенциальные участники сталкивались с трудностями, пытаясь работать с ядром. Сообщество ядра вывело свои собственные особые способы работы, которые позволяют ему функционировать гладко (и производить высококачественный продукт) в среде, где каждый день меняются тысячи строк кода. Поэтому неудивительно, что процесс разработки ядра Linux сильно отличается от патентованных методов разработки.

Для новых разработчиков процесс разработки ядра может показаться странным и пугающим, но за этим стоят веские причины и солидный опыт. Разработчика, не понимающаго принципов работы сообщества (или, что хуже, пытающегося не следовать им или обходить их) постигнет разочарование. Сообщество разработчиков, пытаясь быть полезным для тех, кто старается учиться, не тратит время на тех, кому не интересен или не важен процесс разработки.

Мы надеемся, что читатели этого документа смогут избежать такого разочарования. Здесь много материала, но затраты на его прочтение будут скоро вознаграждены. Сообщество разработчиков всегда нуждается в разработчиках, которые помогут сделать ядро лучше; это руководство должно помочь вам - или тем, кто на вас работает - присоединяйтесь к нашему сообществу.

1.3: АВТОРЫ

Этот документ был написан: Джонатан Корбет (Jonathan Corbet), corbet@lwn.net.
Он был улучшен комментариями: Джеймс Берри (James Berry), Алекс Чианг (Alex Chiang), Роланд Драйер (Roland Dreier), Рэнди Данлэп (Randy Dunlap), Джейк Эдж (Jake Edge), Жири Кошина (Jiri Kosina), Мэтт Мэкалл (Matt Mackall), Аманда МакФерсон (Amanda McPherson), Эндрю Мортон (Andrew Morton), and Йохен Восс (Jochen Voß).

Linux Foundation поддержала эту работу. Особенно благодарим Аманду Макферсон (Amanda McPherson), которая оценила проделанную работу и помогла этому всему состояться.

1.4: ВАЖНОСТЬ ВКЛЮЧЕНИЯ КОДА В ОСНОВУЮ ВЕТКУ

Некоторые компании порой удивляются, почему это они должны разбираться с тем, как устроено сообщество разработчиков ядра, чтобы внести свой код в основую ветку разработки (основная ветка содержит код ядра, который проверяется и включается в него самим Линусом Торвальдсом; это ядро производители дистрибутивов используют как основу). На первый взгляд, включение кода может вызвать расходы, которых можно избежать; кажется, что легче держать этот код отдельно и оказывать поддежку пользователям напрямую. Но правда состоит в том, что содержание кода отдельно ("вне репозитория") - только кажущаяся экономия.

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

- Код, который включен в основную ветку ядра, доступен всем пользователям Linux. Он будет автоматически присутствовать во всех дистрибутивах, которые содержат это ядро. Отпадает необходимость в рассылке дисков, скачивании или удручающей поддержке множества различных дистрибутивов с множеством версий; и все же это безошибочно работает, но только для конкретного разработчика и конкретного пользователя. Включение кода в основую ветку решает много проблем с его распространением и поддержкой.

- В то время как разработчики ядра стараются поддерживать стабильный интерфейс пространства пользователя, внутренний API ядра находится в постоянном движении. Отсутствие устойчивого внутреннего интерфейса - сознательное решение; оно позволяет делать капитальные изменения в любой момент и приводит к более качественному коду. Но одним из результатов такой стратегии является необходимость постоянной поддержки работоспособности кода, находящегося вне репозитория, чтобы он работал с новыми ядрами. Поддержка кода вне репозитория требует значительного объёма работы, только ради содержания кода в рабочем состоянии.

- Код в основной ветке, напротив, не требует всех этих усилий из-за простого правила, требующего от разработчиков приводить в порядок любой код, который повреждается в результате изменений API. Так, поддержка кода, внесенного в основную ветку, обходится гораздо дешевле.

- Кроме того, код, находящийся в ядре, часто улучшается другими разработчиками. Предоставление вашим пользователям и клиентам возможности улучшать ваш продукт может привести к удивительным результатам.

- Код ядра подлежит рецензированию, как до, так и после внесения в основную ветку. Вне зависимости от навыков автора, в процессе проверки неизменно находятся способы улучшения кода. Зачастую рецензенты находят серьезные ошибки и проблемы безопасности. Это особенно касается кода, разработанного в закрытой среде; такой код много выигрывает от проверок внешними разработчиками. Код вне репозитория является менее качественным.

- Участие в процессе разработки - ваш способ повлиять на направление разработки ядра. Сторонние пользователи тоже будут услышаны, но у активных разработчиков больше прав голоса и возможность осуществлять изменения, которые сделают ядро более подходящим для их задач.

- Когда код поддерживается отдельно, всегда существует возможность, что кто-то другой добавит другую имплементацию фунциональной возможности аналогичной вашей. Если это произойдет, добавить ваш код будет гораздо труднее или почти невозможно. Тогда вам остаются две неприятные альтернативы: (1) вечно поддерживать нестандартную функциональность вне репозитория, или (2) отказаться от своего кода и перевести своих клиентов на версию в репозитории.

- Добавление кода - главное действие, заставляющее работать весь процесс. Добавляя свой код, вы можете добавить новую функциональность в ядро и обеспечить возможности и примеры, полезные для других разработчиков. Если вы написали (или подумываете написать) код для Linux, вы, очевидно, заинтересованы в дальнейшем успехе этой платформы; добавление кода - один из лучших путей обеспечения этого успеха.

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

Однако, есть дополнительные факторы, которые следует принять во внимание перед решением о распространении кода ядра в бинарном виде. Среди них:

- Правовые вопросы, связанные с распространением проприетарных модулей ядра, как минимум туманны; немало владельцев авторских прав на ядро считают, что большая часть бинарных модулей являются производными ядра и, следовательно, их распространение - нарушение общедоступной лицензии GNU (о которой будет рассказано ниже). Автор не юрист, и этот документ не следует рассматривать как юридическую рекомендацию. Настоящий юридический статус модулей закрытого кода может быть определен только судом. Но неопределенность, преследующая эти модули, тем не менее остается.

- Бинарные модули значительно увеличивают сложность нахождения и исправления ошибок в ядре до такой степени, что многие разработчики ядра даже не будут пытаться их исправить. Таким образом, распространение ваших модулей в бинарном виде усложняет вашим пользователям получение поддержки от сообщества.

- Так же усложняется поддержка для дистрибьюторов бинарных модулей, которые должны обеспечить версию модуля для каждого дистрибутива и каждой версии ядра, которую они захотят поддерживать. Чтобы обеспечить достаточно полный охват, могут понадобится десятки сборок единственного модуля, а ваши пользователям придется отдельно обновлять ваш модуль при каждом обновлении своего ядра.

- Все, сказанное выше о проверке кода, вдвойне применимо к закрытому коду. Так как этот код никому не доступен, он не будет проверен сообществом и, несомненно, будет содержать ошибки.

Производители встроенных систем, в частности, бывают склонны пренебрегать большей частью сказанного здесь, будучи уверенными, что они выпускают самостоятельный продукт, который использует фиксированную версию ядра и не нуждается в дальнейшей разработке после релиза. Такая аргументация упускает из виду полезность широкого рецензирования кода и ценность предоставления пользователям возможности наращивать функциональность вашего продукта. Но у этих продуктов тоже ограниченный период коммерческой жизни, после которого должна выйти новая версия. На этом этапе производители, чей код находится в основной ветке и достойно поддерживается, окажутся в гораздо лучшем положении, которое позволит им быстро подготовить новый продукт для рынка.

1.5: ЛИЦЕНЗИРОВАНИЕ

Код добавляется в ядро Linux под различными лицензиями, но весь он должен быть совместим со 2-й версией общедоступной лицензии GNU (GPLv2), которая охватывает всё ядро в целом. На практике это означает, что весь добавляемый код покрывается GPLv2 (возможно, с формулировкой, разрешающей распространение согласно последующим версиям GPL) или трех-пунктной лицензией BSD. Добавления, не защищенные совместимой лицензией, не будут приняты в ядро.

При добавлении кода в ядро не требуется (или не запрашивается) передача авторских прав. Права собственности сохраняются на весь код, объединенный в основной ветке; в результате чего сейчас у ядра тысячи владельцев.

Одним из следствий такой собственности является то, что любая попытка изменить лицензирование почти несомненно обречена на провал. Существует несколько практических сценариев, по которым должно быть получено согласие всех авторов (или их код удален из ядра). Таким образом, в обозримом будущем не ожидается миграции к 3-й версии GPL.

Весь код, добавленный в ядро, обязательно должен быть законно бесплатным программным обеспечением. Поэтому анонимный (или псевдоанонимный) код не будет принят. Все участники должны "отдать" свой код, заявив, что код может распространяться вместе с ядром под GPL. Код, который не был лицензирован автором как свободное ПО, или который чреват проблемами с авторскими правами для ядра (например код, полученный посредством попыток инженерного анализа, которому не достает безопасности) не может быть добавлен.

В рассылках Linux разработчиков часто встречаются вопросы, касающиеся авторских прав. Такие вопросы обычно получают достаточно ответов, но полезно помнить, что люди, отвечающие на эти впросы - не юристы, и не могут давать юридические советы. Если у вас возникли правовые вопросы, касающиеся исходного когда Linux, нет ничего лучше консультации с юристом, знакомым с этой областью. Рискованно полагаться на ответы, полученные в технических рассылках.

2: ПРОЦЕСС РАЗРАБОТКИ

В начале 1990-х разработка ядра Linux была нечеткой штукой, со сравнительно небольшим количеством пользователей и разработчиков. После того, как в течение одного года база пользователей увеличилась до миллионов, а количество участвующих разработчиков стало около 2000, ядру пришлось начать вырабатывать набор процессов, чтобы разработка шла плавно. Для эффективного участия в процессе необходимо его полное понимание.

2.1: ОБЩАЯ КАРТИНА

Разработчки ядра используют процесс релизов, нежестко контролируемый по времени, с крупным релизом ядра каждые 2-3 месяца. Новейшая история релизов выглядит следующим образом:

2.6.26 - 13 июля 2008 г.

2.6.25 - 16 апреля 2008 г.

2.6.24 - 24 января 2008 г.

2.6.23 - 9 октября 2007 г.

2.6.22 - 8 июля 2007 г.

2.6.21 - 25 апреля 2007 г.

2.6.20 - 7 февраля 2007 г.

Каждый 2.6.x релиз - крупный релиз ядра с новой функциональностью, изменениями во внутреннем API, и так далее. Типичный 2.6 релиз может содержать более 10000 наборов изменений с изменением до нескольких сотен тысяч строк кода. Таким образом, 2.6 - наиболее активный участок в разработке ядра Linux; ядро использует итерационную модель разработки, то есть постоянную интеграцию крупных изменений.

Относительно простая схема используется при объединении патчей для каждого релиза. В начале каждого цикла разработки объявляется открытым окно принятия (период принятия патчей). В это время код, который считается достаточно надежным (и который одобрен сообществом), добавляется в основную ветку ядра. Масса изменений для нового цикла разработки (и все крупные изменения) будут объединены в течение этого времени порциями около 1000 изменений ("патчей" или "наборов изменений") в день.

(Стоит упомянуть, что изменения, добавленные в период принятия, не были взяты с потолка; они были собраны, протестированы и выставлены заранее. Позже будет описано, как работает этот процесс).

Период принятия продолжается 2 недели. В конце периода Линус Торвальдс объявляет его закрытым и выпускает первое из "rc" ядер. Для ядра, которому предназначено быть например 2.6.26, релиз, сделанный в конце периода принятия будет называться 2.6.26-rc1. Релиз -rc1 сигнализирует, что прошло время добавления новой функциональности, и пора стабилизировать следующее ядро.

В течение следующих 6-10 недель в основную ветку должны добавляться только патчи, исправляющие ошибки. Иногда разрешаются более серьезные изменения, но такое случается редко; разработчики, пытающиеся добавить новую функциональность вне периода принятия, рискуют получить недружелюбный прием. Основное правило, если вы пропустили период принятия для конкретной функциональности, лучше всего подождать до следующего цикла разработки. (Редкие исключения делаются для драйверов для железа, которое раньше не поддерживалось; если они не касаются существующего кода, они не вызовут отката, и добавление должно быть безопасным в любое время).

В ходе добавления исправлений в основную ветку поток патчей постепенно замедляется. Линус выпускает новое -rc ядро примерно раз в неделю; обычно цикл доходит до -rc6 - -rc9, прежде чем ядро посчитают достаточно стабильным, и тогда выходит релиз 2.6.x. На этом этапе весь процесс начинается заново.

Для примера, вот так шел цикл разработки 2.6.25 (все даты относятся к 2008 году):

24 января - 2.6.24 стабильный релиз

10 февраля - 2.6.25-rc1, закрывается период принятия

15 февраля - 2.6.25-rc2

24 февраля - 2.6.25-rc3

4 марта - 2.6.25-rc4

9 марта - 2.6.25-rc5

16 марта - 2.6.25-rc6

25 марта - 2.6.25-rc7

1 апреля - 2.6.25-rc8

11 апреля - 2.6.25-rc9

16 апреля - 2.6.25 стабильный релиз

Как разработчики решают, когда зарыть цикл разработки и сделать постоянный релиз? Самым важным критерием является список регрессий из предыдущих релизов. Отсутствие ошибок - это хорошо, но исправления, которые нарушают работу ранее работавших систем, считаются особенно серьезными. Поэтому, во время периода стабилизации патчи, повлекшие за собой регресии не встречают благосклонности и зачастую удаляются.

Цель разработчиков - исправить все известные регрессии до постоянного релиза. В реальном мире такого совершенства достичь трудно; в проекте такого масштаба слишком много переменных.

Приходит время, когда откладывание окончательного релиза только ухудшает ситуацию; гора изменений, ожидающая следующего периода принятия вырастет, обеспечивая еще больше регрессий в следующем цикле. Поэтому большинство 2.6.х ядер выпускаются с букетом известных проблем, с надеждой, что они не слишком серьезные.

После выхода постоянного релиза, его дальнейшая поддержка передается "постоянной команде", которая в настоящее время состоит из Кроа-Хартмана (Kroah-Hartman) и Криса Райта (Chris Wright). Постоянная команда выпускает дополнительные обновления к постоянному релизу, используя схему нумерации 2.6.x.y. Чтобы быть принятым в релиз обновлений патч (1) должен исправлять серьезную проблему и (2) должен быть уже добавлен в основную ветку следующего ядра. Продолжая наш пример с 2.6.25, история (к моменту написания документа) такова:

1 мая - 2.6.25.1

6 мая - 2.6.25.2

9 мая - 2.6.25.3

15 мая - 2.6.25.4

7 июня - 2.6.25.5

9 июня - 2.6.25.6

16 июня - 2.6.25.7

21 июня - 2.6.25.8

24 июня - 2.6.25.9

Постоянные обновления для данного ядра делались в течение приблизительно 6 месяцев; после этого поддержка постоянных релизов полностью ложится на плечи дистрибьютеров, которые распространяют это конкретное ядро.

2.2: ЖИЗНЕННЫЙ ЦИКЛ ПАТЧА

Патчи не попадают в основную ветку прямиком с клавиатуры разработчика. Напротив, это слегка запутанный процесс (в какой-то степени неформальный), который был сформирован для того, чтобы была уверенность, что каждый патч грамотно написан и не имеет ошибок, а так же вносит в основую ветку именно те изменения, которые там хотят видеть. Этот процесс может быть достаточно быстрым для незначительных исправлений, а в случае больших и сомнительных изменений может продолжаться годами. Причина многих разочарований разработчиков в том, что они не до конца понимают этот процесс, или пытаются его обойти.

В надежде снизить вероятность таких накладок, этот документ описывает то, как патч попадает в ядро. Описанное ниже представляет собой что-то вроде идеального процесса. Дальнейшие разделы содержат более детальные разъяснения.

Стадии, через которые в общем случае проходит патч:

- Проектирование. Эта стадия, во время которой планируются реальные требования к патчу и то, как эти требования будут удовлетворены. Проектированием обычно занимаются без привлечения сообщества, но все же лучше заниматься этим настолько в открытую, насколько можно; это может сохранить уйму времени, которое понадобится на перепроектирование в дальнейшем.

- Первоначальная проверка. Патчи отсылаются в нужный список рассылки и разработчики, которые на нее подписаны, пишут все комментарии, которые у них есть. На этом этапе, если все хорошо, должно обнаруживаться большинство проблем.

- Более широкая проверка. Когда патч почти готов к добавлению в основную ветку, он будет принят ответственным за поддержку соответствующей подсистемы - хотя это принятие не гарантирует, что патч доберется до основной ветки. Патч появится в дереве подсистемы и в деревьях подготовки (описанных ниже). В ходе процесса этот этап ведет к еще более серьезному рецензированию патча, и выявлению проблем, появившихся в результате объединения патча с работой других людей.

- Добавление в основную ветку. В конечном итоге, успешный патч будет добавлен репозиторий основной ветки, которой управляет Линус Торвальдс. В это время могут вcплыть дополнительные комментарии и/или ошибки; важно, чтобы разработчик на них реагировал и исправлял найденные проблемы.