Оригинал

Прежде всего хочу сказать спасибо за перевод Zereal, digiwhite, Shtsh, settler и silent, они сделали большую часть работы с переводом и привели текст в читабельное состояние.

Это будет краткое и в то же время простое руководство по использованию Git и тому, как управлять исходными кодами ядра с его помощью.

До появления Git, простейшим способом управления кодом ядра была следующая последовательность действий: скачать код ядра тарболом (архив, собранный утилитой tar и обычно запакованный утилитой gzip. Прим. пер.) с сайта kernel.org и, в дальнейшем, для экономии трафика, обновлять код, скачивая патчи (от англ. patch - заплатка. Прим. пер.), выходящие между релизами, при этом было очень важно то, что патчи имели маленький размер, что позволяло отказаться от загрузки полного архива кода ядра при каждом изменении. Это также позволяло, применив патчи, всего лишь пересобрать только то, что было изменено, вместо полной пересборки ядра заново. Этот способ неплох, он до сих пор применим и, скорее всего, будет существовать всегда. Обычное скачивание архивов по HTTP и FTP подходит во многих ситуациях.


Однако, появление ядра версии 2.6, его стабильных веток (к примеру, ветка версии 2.6.32.y) и Git, привело к некоторым изменениям. Прежде всего, сейчас процесс немого усложнился. Стабильные патчи применяются к основному релизу. Если у вас код ядра версии 2.6.32.1, и вы хотите перейти на версию 2.6.32.2, вам понадобится отменить изменения, внесенные для релиза 2.6.32.1 (patch --reverse), и применить патч для 2.6.32.2. Это несколько менее удобно, и, кроме того, вам придется модифицировать все файлы, которые изменялись патчами до текущего момента. Это повлияет на последующий процесс компиляции. Другими словами, если патч для 2.6.32.1 означает (фигурально выражаясь) долгую по времени сборку, потому что он затрагивает большую часть системы, то таким же (долгим, прим. пер.) будет процесс сборки последующих релизов ветки версии 2.6.32.y. И это тот маленький недостаток, который подтолкнул меня к управлению исходным кодом ядра способом, описанным ниже. К тому же, использовать Git забавно. :)

Мы попробуем достичь следующего:


(важно что имеется две ветки, и обе стабильны, прим. пер.)

У нас будет основная ветка, которая будет отслеживать основную ветку Линуса и обновляться время от времени или при выпуске новой стабильной версии ядра Linux (к примеру 2.6.32 (на момент написания статьи версия 2.6.32 еще не вышла, прим. пер.))

У нас будут и другие локальные ветки для отслеживания стабильного релиза Грега (Greg K-H), к примеру: 2.6.30.y, 2.6.31.y, 2.6.32.y и так далее.

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

Для начала, мы создадим директорию для хранения исходного кода ядра. Давайте назовем ее /path/to/kernel (тут и далее будут указанные вами папки.прим. пер.). В ней будут: одна директория “src” (сокращено от source - исходный код прим. пер.), в которой мы будем хранить "чистый" код ядра, и вторая директория “build”(сборка), которую мы будем использовать для сборки ядра и сохранения исходного кода ядра незатронутым (того. что в папке “src”, прим. пер.). Начнем с "клонирования" ветки Линуса:

1 2 3 4 5 6

cd /path/to/kernel mkdir build git clone 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' src

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

Используя команду “git branch”, вы увидите, что имеется только одна локальная ветка “master”. Эта локальная ветка будет отслеживать основную ветку Линуса. Если в данный момент вы работаете с этой веткой, то можете обновить ее просто выполнив команду "git pull".

Теперь мы добавим вторую ветку, которая будет ответвляться от ветви стабильного релиза 2.6.32.y. Другими словами, наша ветка выходит из основной ветки Линуса, а ветка “branch_2.6.32.y” (назовем ее так), будет расти из основной ветки из репозитория со "стабильным" кодом версии 2.6.32.y.

Прежде всего, для удобства мы сделаем ярлык на репозиторий 2.6.32.y:



Название “remote_2.6.32.y” является аббревиатурой. Пока что это просто сокращение к длинной ссылке, не более того. Следующий этап очень важен, в нем имя ярлыка становится гораздо большим, чем просто именем, и следующие команды git "поймут", что вы имели ввиду, когда вы воспользуетесь им. Под этим именем данные загрузятся в ваш репозиторий.



После использования данной команды, занимающей меньше времени, чем копирование полного репозитория (его клон мы уже сделали), remote_2.6.32.y станет не просто ссылкой на вашем жестком диске. Затем наберите:



В вашем локальном репозитории появится новая ветка,в которой будет отслеживаться основная ветка репозитория 2.6.32.y. И если вы выполните команду “git branch”, то увидите, что появилось две ветки. У “tracking branch” (ветка наблюдения - та, что следит за изменениями другой ветки. прим. пер.) есть несколько значений. Вы можете выбирать между master branch и новой веткой, используя “git checkout <название ветки>”, и в каждой из них выполнить “git pull” для обновления этой ветки с удаленного репозитория. С этого момента вы сам себе хозяин при использования Git для управления кодом и выполнения дополнительных операций, если считаете нужным, к тому же в интернете доступно много инструкций для понимания основ Git. И это все, что вам требуется для управления исходным кодом ядра, с единственной целью - упростить процесс скачивания и сборки.

Заметим, что, например, между релизами 2.6.32.1 и 2.6.32.2, вам надо будет скачать изменения между ними, и мучительная сборка 2.6.32.1 не обязательно значит мучительную сборку 2.6.32.2, если вы обновляете свой код таким образом.

В конце концов, в дополнении к директории "src" мы создали директорию “build”. Она нужна, чтобы содержать первую (с кодом) в чистоте. Теперь мы можем с легкостью использовать ее. Когда мы находимся в директории “src”, любая команда "make”, которую мы используем, должна быть заменена на “make O=../build”. Для предотвращения ошибок, я создал глобальный alias в моей системе под названием “kmake”, который означает “make O=../build”. Для обычного пользователя alias используется для компиляции ядра, для root - в процессе установки, а также при выполнении “modules_install”, “firmware_install” и “install” операций.

При использовании учетной записи обычного пользователя:

1 2 3 4 5

kmake menuconfig kmake kmake oldconfig

и так далее.
(тут и далее под root приводятся простые аналоги команд make для примера, и нет смысла в последовательности, как и цели в выполнении. прим. пер.)

При использовании учетной записи root:

1 2 3 4 5

kmake modules_install kmake firmware_install kmake install

Аliases могут быть настроены для дальнейшей сборки образа ядра, модулей, прошивки и так далее в sandbox (дословно "песочница" прим. пер.), если вы, к примеру, планируете создать пакеты для них. Файл README в папке с исходными текстами ядра содержит больше информации по этой теме.