- Установка патчей в Linux – работа с утилитой patch
- Что такое патч?
- Синтаксис и основные опции команды patch
- Применение патчей к отдельным файлам
- Работа с проектами
- K210.ORG
- This page REALLY is just for me to remember
- Поиск
- Работа с патчами
- Применение патчей к ядру Linux
- Что такое патч (patch)?
- Как применить или отменить патч?
- Как передавать файл заплатки/патча программе ‘patch’?
- Основные ошибки
- Есть ли альтернативы программе ‘patch’?
- Где я могу скачать патчи?
- Ядра 2.6.x
- Ядра 2.6.x.y
- Ядра -rc: релиз-кандидатные ядра
- Ядра -git
- Ядра -mm
Установка патчей в Linux – работа с утилитой patch
Практически каждый разработчик программного обеспечения (ПО), программист или верстальщик сталкивается (и довольно часто) с необходимостью модификации некоторой части рабочего проекта или даже нескольких строк кода. Особенно это актуально, когда в разработке участвует несколько человек, которые могут вносить правки в разных частях проекта. Для удобства и автоматизации действий по составлению таких правок используются специализированные утилиты. Одной из таких является утилита patch и о ней более подробно будет рассказано в данной статье.
Что такое патч?
Говоря о патчах вкупе с утилитой patch, следует подразумевать, что это касается исключительно текстовых данных. Другими словами, происходит работа с исходными кодами проекта, будь то код C++, PHP, HTML и т. д. Вообще, все самые «суровые» программисты или разработчики в процессе своей совместной работы над проектом обмениваются исключительно отдельными правками, а не пересылают друг другу актуальные версии проектов целиком.
Сама правка, т. е. текстовые изменения в исходном коде проектов (для одного его файла или сразу для нескольких) и есть патч или «заплатка». Патч, помимо самих изменений кода содержит также и некоторую служебную информацию, необходимую для правильного «наложения заплатки», т. е. для установки патча. Таким образом, патч — это текстовый файл определённого формата, содержащий в себе данные и инструкции для приведения конечного файла (или проекта) к нужному или актуальному виду.
Утилита patch умеет быстро и эффективно распоряжаться данными из файла-патча, используя для этого хранящиеся в нём инструкции. И таким образом выполняет все рутинные действия по редактированию. Пользователю (разработчику) необходимо лишь правильно выполнить соответствующую команду, задав все необходимые аргументы и опции.
Синтаксис и основные опции команды patch
Нет ничего удивительного в том, что утилита patch относится к категории ПО, которое обязательно должно быть установлено на любой машине для разработки программ, да и вообще для ведения разработки. Практически любой дистрибутив Linux предоставляет утилиту patch предустановленной по-умолчанию.
Стоит также отметить, что по своей функциональности, patch довольно сложна и обладает, без преувеличения, просто огромным набором опций. По этой причине в данной статье будут приведены только самые распространённые приёмы при работе с этой утилитой и только сопутствующие им опции команд. Синтаксис команды patch следующий:
Здесь originalfile – это файл, который необходимо «пропатчить» до актуального состояния. А patchfile – файл-патч. Сразу возникает вопрос: а откуда берётся этот файл-патч? Ответ: он генерируется другой утилитой — diff, которая находит построчные различия между файлами. Либо же патч может быть составлен вручную, автором, если он знаком с соответствующим форматом. Но это бывает крайне редко, обычно прибегают к помощи diff или её аналогов.
В следующей таблице приведены опции команды patch, которые используются наиболее часто:
Опция | Значение |
-i patchfile | Читает информацию из патч-файла, указываемого параметром patchfile. |
-r rejectfile, —reject-file=rejectfile | |
-N, —forward | Когда патч не применяется, то утилита patch обычно пытается определить, выглядит ли ситуация так, как если бы патч уже был применён. Опция -N отключает такое поведение. |
-pnum, strip=num | Обрезает части пути к файлу, разделяемые символом косой черты до уровня, указанного в параметре num. Например: p0 оставит путь /u/john/src/blurfl/blurfl.cpp неизменным, а p4 обрежет тот же путь до blurfl/blurfl.cpp. |
-o outputfile, —output=outputfile | Отправляет вывод в указываемый в параметре outputfile файл. Не следует использовать эту опцию, если в качестве outputfile указывается файл, который должен быть пропатчен. Если в качестве outputfile указать символ дефиса «-», то вывод будет направляться в стандартный поток STD_OUT. |
-E, —remove-empty-file | Удаляет файлы, оказавшиеся пустыми после применения патча. Эта опция имеет смысл, когда используемые патчи имеют не контекстный формат. |
—dry-run | Печатает результаты применения патча без реальной модификации файлов. Полезно для быстрого и безопасного тестирования патчей. |
-R, —reverse | Откатывает все изменения (если они возможны), т. е. отменяет установку патча. |
-c, —context | Интерпретирует файл патча как обычный контекстный формат, генерируемый утилитой diff. |
-b, —backup | Создаёт резервную копию оригинального файла вместо его удаления. |
Применение патчей к отдельным файлам
Прежде, чем начать рассмотрение практических примеров, необходимо сказать несколько слов о той самой утилите, которая и создаёт патчи — diff. Она может генерировать патчи трёх типов — простой, контекстный и контекстный унифицированный. Простой гораздо более компактный по размеру, чем контекстные, но последние гораздо более удобочитаемы и понятны для восприятия пользователем. Для того, чтобы сгенерировать простой патч, для команды diff никаких специальных опций не требуется. А для генерации контекстного или унифицированного контекстного патчей предназначены опции -с и -u соответственно:
Пусть имеется файл с кодом C++ ChildClass.cpp:
И пусть в этот файл было внесено следующее изменение: метод valueSqr() был переименован в calcSqr(). Тогда контекстный патч (файл contextpatch) будет выглядеть следующим образом:
Теперь, чтобы пропатчить старую версию ChildClass.cpp, нужно выполнить команду:
В результате будет получен файл ChildClass_new.cpp с актуальным содержимым.
Работа с проектами
С помощью утилиты patch можно также применять патчи для нескольких файлов, причём расположенных в разных каталогах. Это удобно, когда изменения проводятся в масштабах целого проекта. Но в этом случае и сам патч должен быть особым образом подготовлен утилитой diff.
Пусть имеется старый проект в каталоге base-project. Внутри него имеются подкаталоги include и src, в которых, в свою очередь находятся файлы с изменениями — ChildClass.h (в каталоге include) и ChildClass.cpp (в каталоге src). Сам изменённый (актуальный) проект был помещён в отдельный каталог new-project. Подготовка патча будет выглядеть следующим образом:
Сгенерированный файл-патч project-patch:
Следует обратить внимание, что в данных примерах указываются относительные пути. Файл-патч будет помещён в текущий активный каталог.
Чтобы применить патч нужно выполнить следующую команду:
Как видно, вместо ключа -i можно использовать символ «
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Источник
K210.ORG
This page REALLY is just for me to remember
Поиск
Работа с патчами
В мире Linux широко используется пара программ diff и patch. diff создает файл, в который записываются различия между 2 файлами или 2 каталогами (т.н. патч), а patch позволяет «наложить» этот патч, т.е. имея патч и один из двух файлов (каталогов), получить другой. Основное применение этих программ — создание, распространение и применение патчей к исходным текстам программ. Например, я нашел ошибку в к.-л. программе и после изучения ее исходного кода понял, что для исправления этой ошибки надо добавить 2 строчки, а еще в одной поменять несколько символов. Я хочу сообщить разработчику об этом, но каким образом указать ему на требуемые изменения? Можно это сделать обычным языком, но гораздо лучше (и удобнее для нас обоих) сделать патч и выслать его разработчику.
Или другой пример. Ядро Linux, упакованное в .tar.bz2, весит более 30 Мб независимо от его версии. Но файл различий между версиями 2.6.6 и 2.6.7, упакованный в .bz2, весит всего 3 Мб, поэтому для получения исходников ядра 2.6.7 из исходников ядра 2.6.6 достаточно скачать лишь 3 Мб, не выкачивая все 32 Мб заново.
Впрочем, часто нужно просто посмотреть различия 2 почти одинаковых файлов, и для этого тоже удобно использовать diff, выводя результат его работы не в файл, а прямо на экран.
А теперь посмотрим работу этих утилит на практике. Возьмите какой-нибудь текстовый файл и сделайте его копию, а затем отредактируйте эту копию — 1-2 строчки удалите, что-нибудь добавьте, пару строчек просто поменяйте. Затем запустите diff старый_файл новый_файл. Получите файл различий в обычном формате. В нем выводятся только измененные строки, и изменения помечены символами (означающими, что соответствующая строка принадлежит левому или правому файлу в командной строке). Этот формат пригоден только для изучения человеком небольших различий между 2 файлами. Для создания патчей используются другие форматы вывода, задаваемые дополнительными опциями, при этом результат работы diff перенаправляется в файл патча стандартными средствами оболочки.
Добавьте к строке вызова diff ключ -u. Теперь вывод программы будет представлять собой патч в унифицированном формате, который используется в большинстве случаев (есть еще контекстный формат, включаемый ключом -c, но он используется намного реже). В такой патч включаются и несколько соседних неизмененных строк (т.н. контекст), помогающие программе patch найти место в файле, где произошло изменение. Добавленные во 2-м файле строки помечаются плюсами, удаленные — минусами. Если строка изменилась, она выводится 2 раза — старый вариант с минусом и новый с плюсом. Кроме того, в начале добавляется заголовок, в котором указываются имена и даты изменения обоих файлов.
diff позволяет получить различия между двумя каталогами. Это используется, как правило, чтобы получить общий патч ко всему дереву исходников программы, если было изменено несколько файлов. Для этого используются ключи -urN, а вместо 2 файлов указываются имена 2 каталогов (старого и измененного). При этом корректно обрабатываются ситуации с созданными/удаленными файлами (файл, отсутствующий в одном из каталогов, считается существующим и пустым).
Чтобы наложить патч, надо перейти в каталог, где находится старый файл/каталог, и выполнить команду
При использовании патчей к каталогам обычно делают так: патч создается, как описано выше (тогда в заголовках патчей к отдельным файлам путь к ним будет начинаться с имени нового каталога), а прикладывается он внутри изменяемого каталога. Тогда команда будет выглядеть так:
Здесь -p1 означает, что из заголовков патча надо убрать начальный каталог. Поясню всё это на примере. У нас имеется дерево исходников ядра 2.6.0. Это каталог linux-2.6.0, в котором содержатся каталоги drivers, arch и т.д. И у нас есть патч до версии 2.6.1, в котором содержатся такие заголовки:
— a/drivers/acpi/Kconfig Thu Jan 8 23:00:24 2004
+++ b/drivers/acpi/Kconfig Thu Jan 8 23:00:24 2004
Видим, что при создании патча старый и новый каталоги назывались a и b соответственно. У нас же каталог называется по-другому, и patch ничего сделать не сможет. Поэтому заходим в каталог linux-2.6.0 и выполняем указанную выше команду. Теперь заголовки будут интерпретироваться как
— drivers/acpi/Kconfig Thu Jan 8 23:00:24 2004
+++ drivers/acpi/Kconfig Thu Jan 8 23:00:24 2004
Источник
Применение патчей к ядру Linux
Джеспер Джал (Jesper Juhl), перевод Олега Смагина aka saturn721
Часто задаваемый вопрос в списке рассылки ядра линукс — это как применить патч к ядру, или, точнее, какой патч для какой версии ядра подходит. В данном документе это объясняется.
В дополнение к объяснению того, как применять и отменять патчи, здесь приводится краткое описание структуры различных ветвей ядра (и примеров того, как применять их конкретные патчи).
Что такое патч (patch)?
Патч, или заплатка — это небольшой текстовый документ, содержащий суть изменений между двумя разными версиями исходных текстов. Патчи создаются с помощью программы ‘diff’. Для правильного применения патча вам нужно знать, на основе чего он был создан, и в какую новую версию патч превратит исходные тексты ядра. И то и другое может быть представлено в метаданных файла патча и, возможно, в его названии.
Как применить или отменить патч?
Патч применяется с помощью программы ‘patch’. Эта программа читает файл различий (или патч) и делает изменения в нужных местах исходных текстов.
Патчи для ядра Linux генерируются относительно родительского каталога, содержащего исходные тексты ядра.
Это означает, что пути к файлам внутри файла патча содержат имя директории исходных текстов ядра, относительно которой этот патч генерировался (или имена некоторых других директорий подобно «a/» или «b/»).
Поскольку это имя вряд ли будет совпадать с именем директории исходных текстов ядра на вашей машине (хотя часто оно помогает увидеть, для какой версии ядра был создан данный патч), вам следует перейти в свою директорию, содержащую исходные тексты ядра и затем отбросить первый элемент в путевых именах файлов в файле патча до того, как его применить (для этого служит ключ -p1 в программе ‘patch’).
Чтобы отменить примененный патч, используйте ключ -R. Например, если вы применили патч следующим образом:
то отменить его можно так:
Как передавать файл заплатки/патча программе ‘patch’?
Это (как и в других Unix-подобных системах) может быть сделано несколькими способами. Во всех примерах, указанных ниже, я передаю файл (в разархивированном виде) программе через стандартный ввод, используя следующий синтаксис:
Если для вас этого достаточно, можете дальше не читать этот раздел.
Программе ‘patch’ можно передать имя файла, используя ключ -i, как в следующем примере:
Если файл патча содержится в архиве gzip или bzip, и вы не хотите распаковывать его заранее, можно вызвать ‘patch’ так:
Если файл патча содержится в архиве, и вы хотите разархивировать его вручную до применения, (в примерах ниже это предполагается), это можно сделать так:
Это даст вам обычный текстовый файл, который можно передавать программе ‘patch’ через стандартный ввод или через ключ -i, как вам захочется.
К числу других интересные ключей программы ‘patch’ относятся -s, вынуждающий программу не выводить никаких сообщений, кроме сообщений об ошибках, что позволяет лучше их заметить, и ключ —dry-run который заставляет программу просто выдать листинг того, что будет происходить, а в реальности ничего не менять. Наконец, ключ —verbose указывает программе ‘patch’ о потребности вывода максимума информации о происходящем.
Основные ошибки
Когда программа ‘patch’ применяет патч, она пытается проверить файл разными способами. В частности, проверяется, что файл является допустимым патч-файлом и что код, окружающий биты, которые должны быть изменены, соответствует контексту патча.
Если программа ‘patch’ считает, что в патче что-то выглядит неправильно, она может выбрать один из вариантов поведения — отказаться проводить изменения и закончить работу или попытаться найти способ применения патча с небольшими изменениями.
Один из примеров ситуации «что-то не так», которую программа пытается исправить, — это когда контекст изменений присутствует, нужные строки находятся, но у них другие номера. Так может случиться, к примеру, если программа ‘patch’ делает изменения в середине файла, но по каким-то причинам несколько строк в начале файла были добавлены или удалены. Если все остальное в порядке, программа обычно подгоняет номера строк и применяет патч.
Всякий раз, когда программа ‘patch’ применяет патч с его предварительной модификацией, она сообщает вам, что патч применен с ‘подгонкой’ (‘fuzz’).
Вы должны быть осторожны с подобными изменениям, поскольку даже если все выглядит верно, это не всегда так, и что-либо может быть неправильно.
Когда программа встречает изменения, которые она не может сделать даже с подгонкой, она отвергает их и производит файл с расширением .rej (reject file). Вы можете прочитать его, чтобы точно узнать, какие изменения не удалось применить, и при желании что-то исправить.
Если вы не применяете к исходным текстам своего ядра неофициальные патчи, а используете только патчи с ресурса kernel.org, применяя их в правильном порядке, и не делаете самостоятельных изменений в исходных текстах ядра, то вы никогда не увидите сообщений ‘fuzz’ или ‘reject’ от программы ‘patch’. Если они будут выдаваться, это свидетельствует об порче ваших локальных исходных текстов или скаченного патча. Вам стоит попробовать снова закачать патч, а если и это не устранит проблемы, то следует скачать полные исходные тексты ядра с kernel.org.
Давайте посмотрим на другие сообщения, которые может генерировать программа ‘patch’.
Если программа останавливается и выводит сообщение «File to patch:», значит она не смогла найти файл патча. Обычно это означает, что вы забыли указать ключ -p1 или находитесь не в нужной директории. Но иногда так случается, когда вы применяете патч, для которого нужен ключ -p0, а не -p1 (исследуйте файл патча на предмет этого, и если это так, то это ошибка человека, создавшего патч, и она поправима ).
Если вы получили сообщение «Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines).» или подобное, это означает, что программа ‘patch’ регулировала применяемые изменения (в данном случае пришлось передвинуться на 7 строк от того места, где они должны были применяться, чтобы их стало можно применить). Результирующий файл может получиться правильным или неправильным в зависимости от причин, по которым исходный файл был не таким, как ожидалось. Так часто случается, когда вы пытаетесь применить патч не к той версии ядра.
Если вы получили сообщение «Hunk #3 FAILED at 2387.», это означает что программа не смогла применить патч даже с подгонкой. В этом случае генерируется файл .rej с информацией о неудавшемся изменении, а также файл с расширением .orig, содержащий оригинальный текст, который не удалось заменить.
Сообщение «Reversed (or previously applied) patch detected! Assume -R? [n]» означает, что программа обнаружила, что патч уже применен.
Если вы действительно применяли этот патч и вторичное применение — это ошибка, нажмите [n] и завершите выполнение программы. Если вы применяли его, а теперь хотели отменить, просто забыв ключ указать -R, нажмите [y]. Такое также случается, когда человек, создававший патч, поменял местами исходный и целевой каталоги, и в этом случае применение патча и заключается в отмене изменений.
Сообщение «patch: **** unexpected end of file in patch» или «patch unexpectedly ends in middle of line» означает, что программа не может обнаружить в файле патча нужное содержание. Это значит, что либо вы некорректно загрузили патч, либо пытаетесь применить патч не в разархивированном виде, либо применяете патч, переданный через почтовый клиент или что-то и подобное, разбивающее длинные строки на две. Зачастую такие предупреждения могут легко быть устранены путем объединения (конкатенации) таких двойных строк.
Как ранее указывалось, эти ошибки не могут проявиться, когда вы применяете официальные патчи с ресурса kernel.org в правильном порядке и к не измененным исходным текстам ядра. Таким образом, если это случается с патчами с kernel.org, это обозначает искажение патча при загрузке или исходных текстов на вашей машине, и вам стоит полностью заново перекачать исходные тексты ядра или патч, который вы намерены применить.
Есть ли альтернативы программе ‘patch’?
Можно использовать программу ‘interdiff’ (http://cyberelk.net/tim/patchutils/) для создания патча, представляющего разницу между двумя патчами, и дальнейшего его применения.
Она позволит вам перейти, например, от 2.6.12.2 к 2.6.12.3 за один шаг. Флаг -z программы interdiff позволяет работать с патчами в архивах gzip и bzip2, не извлекая их заранее вручную и без использования zcat и bzcat.
Однако, хотя эта программа поможет вам сэкономить один или два шага, рекомендуется применять все шаги, поскольку в некоторых случаях interdiff может сработать неправильно.
Другой альтернативой является сценарий ‘ketchup’, написанный на языке python, который автоматически скачивает и применяет патчи (http://www.selenic.com/ketchup/).
Другими интересными инструментами являются diffstat, который показывает сводку изменений, сделанных программой patch; lsdiff, который выводит краткий перечень файлов, затрагиваемых заданным патч-файлом, вместе с номерами изменяемых строк; и grepdiff, показывающий список файлов, модифицируемых патчем, для которых элементы патча содержат заданное регулярное выражение.
Где я могу скачать патчи?
Патчи доступны на http://kernel.org/ Наиболее свежие патчи доступны с главной страницы, но для них имеются и отдельные страницы.
Взамен ftp.kernel.org вы можете использовать ftp.cc.kernel.org, где cc — код страны. Использование для закачки зеркало из наиболее ближней к вам страны позволяет ускорить загрузку, сократить глобальный трафик и уменьшить нагрузку на сервер kernel.org. Поэтому при наличии возможности используйте зеркала.
Ядра 2.6.x
Имеются основные стабильные релизы, выпускаемые Линусом Торвальдсом. Чем больше номер, тем свежее релиз.
Если обнаруживаются регрессии или другие серьезные недостатки, для этих базовых релизов выпускается исправляющий патч -stable (смотри ниже). Как только выходит новый релиз 2.6.х основной ветки ядра, выпускается и патч, позволяющий перейти к нему от предыдущего релиза.
Чтобы применить патч от 2.6.11 к 2.6.12, нужно сделать следующее (учитывайте что такие патчи не применимы к ядрам версий 2.6.x.y, их можно применять только к базовым версиям 2.6.x ядро — если необходимо перейти от 2.6.x.y к 2.6.x+1, то нужно сперва применить патч, отменяющий 2.6.x.y, т.е. вернуться к 2.6.x).
Вот несколько примеров:
Ядра 2.6.x.y
Ядра с четырехцифренными номерами версий называются -stable. Они содержат минимальные критические исправления, касающиеся проблем безопасности или существенных регрессий, обнаруженных в данном ядре 2.6.х.
Это ветки, которые рекомендуются для пользователей, желающих иметь стабильное ядро и не заинтересованных в разработке и тестировании экспериментальных версий.
Если нет доступного ядра 2.6.x.y, то текущей стабильной версией является ядро с самым большим номером 2.6.x.
Не инкрементальность патча означает, например, что патч 2.6.12.3 подходит для обновления основной версии 2.6.12, но не промежуточной версии 2.6.12.2. Для применения патча 2.6.12.3 к существующему ядру 2.6.12.2 вы должны сперва отменить патч 2.6.12.2 (перейти назад к версии 2.6.12), а затем применить патч 2.6.12.3.
Вот небольшой пример:
Ядра -rc: релиз-кандидатные ядра
Это опытные ядра, выпускаемые Линусом, когда он сочтет, что текущее дерево git (приложение управления исходными текстами ядра) находится в состоянии, достаточно пригодном для тестирования.
Эти ядра не стабильны, и вам следует ожидать периодических проблем, если собираетесь их запускать. Однако они наиболее стабильны среди всех опытных ветвей ядра и, кроме того, в конечном итоге превращаются в стабильное ядро. Таким образом, очень важно тестировать их многим людям.
Это хороший выбор для тех, кто хочет тестировать новые ядра, но, на самом деле, не хочет экспериментировать. (Таким людям следует прочитать ниже разделы -git и -mm ниже).
Патчи -rc — не инкрементальные, они применяются к базовому ядру 2.6.x , подобно патчам 2.6.x.y, отмеченным выше. Часть номера версии ядра до суффикса -rcN указывает номер версии ядра, в которую, в конечном счете, все должно превратиться.
Таким образом, 2.6.13-rc5 означает, что это пятый кандидат-релиз для ядра 2.6.13, и патч должен применяться к версии 2.6.12.
Вот три примера наложения этого патча:
Ядра -git
Эти ежедневные снимки дерева ядра Линуса (сделанные в репозитарии git, поэтому такое название).
Эти патчи обычно ежедневные и представляют текущее состояние версии Линуса. Они более экспериментальные, чем -rc ядра, поскольку генерируются автоматически даже без беглого взгляда на их работоспособность.
Патчи -git — не инкрементальные и применяются к базовому ядру 2.6.х или базовому ядру 2.6.x.rc, что видно из их имен. Патч с именем 2.6.12-git1 применяется к ядру 2.6.12, а патч с именем 2.6.13-rc3-git2 — к 2.6.13-rc3.
Вот несколько примеров применения патчей:
Ядра -mm
Это экспериментальные ядра, выпускаемые Андрю Мортоном (Andrew Morton).
Ветка -mm является неким видом полигона для образования патчей с новыми возможностями и другими экспериментальными особенностями.
После того, как некоторый патч доказывает свою ценность в ветке -mm в течении какого-то времени, Андрю предлагает его Линусу для включения в основную ветку.
Хотя по установленным правилам эти патчи передаются Линусу через ветку -mm, эти правила не всегда соблюдаются. Мейнтейнеры подсистем (или просто разработчики) иногда пересылают свои патчи напрямую Линусу, даже если они были объединены и протестированы в -mm (а иногда даже без предварительного тестирования в -mm).
Для обеспечения максимального тестирования в большинстве случаев следует стремиться получать патчи через -mm.
Эта ветка находится в постоянном развитии и содержит многочисленные экспериментальные возможности; имеется много отладочных патчей, не пригодных для магистральных веток и т.д. Она является наиболее экспериментальной из всех ветвей, описываемых в данном документе.
Эти ядра не подходят для использования в системах, которые должны быть стабильным, при их использовании имеется больше риска, чем при работе с ядрами из какой-либо другой ветки (не забывайте о резервном копировании — это нужно делать при использовании любого экспериментального ядра, и тем более при работе с ядрами из ветки -mm).
Для этих ядер, в дополнение ко всем другим экспериментальным патчам, как правило, поддерживаются различные изменения к основным ядрам ветки -git ядер к моменту выпуска.
Тестирование ядер -mm является весьма похвальным занятием и заключается в том, чтобы отсеять регрессии, отказы, повреждения данных(и другие ошибки) до их применения Линусом в основных ветвях. Но тестировщики ветви -mm должны понимать, что в этих версиях ошибок больше, чем в любой другой.
Версии ядер -mm не выпускаются по какому-либо установленному плану, но обычно в промежутке между выпусками ядер -rc выходит несколько версий ядра -mm (обычно от одной до трех). Патчи ветки -mm применяются к базовому ядру 2.6.x (до выхода -rc версии) или к ветке -rc Линуса.
Вот несколько примеров того, как их применять:
На этом список разъяснений по различным ядра деревьев можно закончить.
Я надеюсь, что вам теперь ясно, как применять различные патчи и помочь в тестировании ядер.
Особая благодарность Рэнди Данлэп (Randy Dunlap), Ролфу Айке Беру (Rolf Eike Beer), Линусу Торвальсу (Linus Torvalds), Бого Эггерту (Bodo Eggert), Йоханнесу Стезенбаху (Johannes Stezenbach), Гранту Коди (Grant Coady), Павлу Мачеку (Pavel Machek) и другим, которых я забыл указать, за помощь в создании данного документа.
Источник