Читаем Linux API. Исчерпывающее руководство полностью

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

После выпуска версии ядра с номером 2.6 модель разработки была изменена. Главной причиной для этого изменения послужили проблемы и недовольства, вызванные длительными периодами между выпусками стабильных версий ядра[1]. Вокруг доработки этой модели периодически возникали споры, но основными остались следующие характеристики[2].

• Версии ядер перестали делить на стабильные и дорабатываемые. Каждый новый выпуск 2.6.z может содержать новые функции. У выпуска есть жизненный цикл, начинающийся с добавления функций, которые затем стабилизируются в течение нескольких версий-кандидатов. Когда такие версии признают достаточно стабильными, их выпускают в качестве ядра 2.6.z. Между циклами выпуска обычно проходит около трех месяцев.

• Иногда в стабильный выпуск с номером 2.6.z требуется внести небольшие исправления для устранения недостатков или решения проблем безопасности. Если эти исправления важны и кажутся достаточно простыми, то разработчики не ждут следующего выпуска с номером 2.6.z, а вносят их, выпуская версию с номером вида 2.6.z.r. Здесь r является следующим номером для второстепенной редакции ядра, имеющего номер 2.6.z.[3]

• Дополнительная ответственность за стабильность ядра, поставляемого в дистрибутиве, перекладывается на поставщиков этого дистрибутива.

В следующих главах иногда будут упоминаться версии ядра, в которых встречаются конкретные изменения API (например, новые или измененные системные вызовы). Хотя до выпуска серии 2.6.z большинство изменений ядра происходило в дорабатываемых ветвях с нечетной нумерацией, я буду в основном ссылаться на следующую стабильную версию ядра, в которой появились эти изменения. Ведь большинство разработчиков приложений, как правило, пользуются стабильной версией ядра, а не одним из ядер дорабатываемой версии. Во многих случаях на страницах руководств указывается именно то дорабатываемое ядро, в котором конкретная функция появилась или изменилась.

Для изменений, появившихся в серии ядра с номерами 2.6.z, я указываю точную версию ядра. Когда говорится, что функция является новой для ядра версии 2.6, без указания номера редакции z, имеется в виду функция, которая была реализована в дорабатываемых сериях ядра с номером 2.5 и впервые появилась в стабильной версии ядра 2.6.0

Портирование на другие аппаратные архитектуры

В начале разработки Linux главной целью было не достижение возможности портирования системы на другие вычислительные архитектуры, а создание работоспособной реализации под архитектуру Intel 80386. Но с ростом популярности Linux стала портироваться на другие архитектуры. Список аппаратных архитектур, на которые была портирована Linux, продолжает расти и включает в себя x86-64, Motorola/IBM PowerPC и PowerPC64, Sun SPARC и SPARC64 (UltraSPARC), MIPS, ARM (Acorn), IBM zSeries (бывшая System/390), Intel IA-64 (Itanium; см. публикацию [Mosberger & Eranian, 2002]), Hitachi SuperH, HP PA-RISC и Motorola 68000.

Дистрибутивы Linux

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