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

Чтобы разрабатывать драйвер, мы должны иметь различные версий ядра linux в виду.

Возможно, лучший способом поддерживать здраво так много задач является возможность выбирать конкретные патчи применяемые для той или иной ситуации. MQ обеспечивает функция называющуюся «стражи» (guards) (которая берет свое начало с командой quilt's guards), которая делает тоже самое. Для начала, давайте создадим простой репозиторий для экспериментов

$ hg qinit
$ hg qnew hello.patch
$ echo hello > hello
$ hg add hello
$ hg qrefresh
$ hg qnew goodbye.patch
$ echo goodbye > goodbye
$ hg add goodbye
$ hg qrefresh

Это дает нам крошечный репозиторий, содержащее два патча, не имеющие никаких зависимостей друг от друга, потому что они затрагивают разные файлы.

Идея применения условия, которое вы можете указать в «тэг» патча со стражем, который является простой текстовой строкой по вашему выбору, которая скажет MQ, выбрать конкретного стража используемого при применении исправлений. MQ потом либо применит, либо пропустить, охраняемый патч, в зависимости от охранника, которого вы выбрали.

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

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

$ hg qguard
goodbye.patch: unguarded

Чтобы установить положительного охранника на патч, используйте префикс «+» перед именем стража.

$ hg qguard +foo
$ hg qguard
goodbye.patch: +foo

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

$ hg qguard -- hello.patch -quux
$ hg qguard hello.patch
hello.patch: -quux

Notice that we prefixed the arguments to the hg qguard command with a -- here, so that Mercurial would not interpret the text -quux as an option.

	Setting vs. modifying
	Команда qguard устанавливает охранников на патч, но не изменять их. Это означает, что при запуске hg qguard +a +b на патч, а затем hg qguard +c на тот же патч, единственным охранником, который будет установлен на него будет +c.

Mercurial сохраняет охранников магазинов в файле series; том виде, в котором они хранятся их легко понять и править руками. (Другими словами, вы не должны использовать qguard команду, если вы не хотите, достаточно просто редактировать файл series).

$ cat .hg/patches/series
hello.patch #-quux
goodbye.patch #+foo

Команда qselect определяет, какие охранники активны в данный момент времени. Результатом этого является определение, какие патчи MQ будет применяться при следующем запуске qpush. Команда не имеет другого эффекта, в частности, она не делает ничего, с уже применёнными патчами.

Без аргументов qselect перечисляет охранников применённых в настоящее время, по одному на строку. Каждый аргумент рассматривается как имя применённого охранника.

$ hg qpop -a
popping goodbye.patch
popping hello.patch
patch queue now empty
$ hg qselect
no active guards
$ hg qselect foo
number of unguarded, unapplied patches has changed from 1 to 2
$ hg qselect
foo

Если вам интересно применённые охранники хранятся в файле guards.

$ cat .hg/patches/guards
foo

Эффект от выбранных охранников мы увидим когда запустим qpush.

$ hg qpush -a
applying hello.patch
applying goodbye.patch
now at: goodbye.patch

Охранник не может начинаться с символа «+» или «-». Имя охранника не должно содержать пробелов, но большинство других символов разрешены. Если вы пытаетесь использовать неверное имя сторожа, MQ будет ругаться:

$ hg qselect +foo
abort: guard '+foo' starts with invalid character: '+'

Изменение выбранных охранников изменяет применяемые патчи.

$ hg qselect quux
number of guarded, applied patches has changed from 0 to 2
$ hg qpop -a
popping goodbye.patch
popping hello.patch
patch queue now empty
$ hg qpush -a
skipping goodbye.patch - guarded by '+foo'

Вы можете увидеть в приведенном ниже примере, что негативные охранники имеют приоритет над положительными охранниками.

$ hg qselect foo bar
number of unguarded, unapplied patches has changed from 0 to 2
$ hg qpop -a
no patches applied
$ hg qpush -a
applying hello.patch
applying goodbye.patch
now at: goodbye.patch

Правила, которые использует MQ при решении вопроса о применении патча состоят в следующем.

В работе над драйвером о котором я говорил ранее, я не применять патчи для нормального дерева ядра linux. Вместо этого я использую репозиторий, который содержит только снимок из исходных файлов и заголовков, которые имеют отношение к разработке Infiniband. Этот репозиторий 1% от размера репозитория ядра, так легче работать.

Я тогда выбрал «основную» версию поверх которой применял патчи. Это снимок дерева ядра linux содержал выбранные мной ревизии. Когда я беру снимок, я записываю id ревизии из репозитория ядра в сообщении фиксации. Поскольку снимок сохраняет «форму» и содержание соответствующих разделов дерева ядра, и я могу применить мои патчи поверх и моего маленького репозитория, и нормальный дерева ядра.

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

Я классифицировал патчи в файле series на несколько логических групп. Каждый раздел патчей начинается с блока комментариев, которые описывают цель исправлении, которые за ним следуют.

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

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

Мы хотели бы также чтоб патчи, которые мы знаем, что нужно изменить должны применяться в верхней части дерева исходных текстов, которая напоминает апстрим дерево, насколько это возможно. Именно поэтому мы постоянно принимаем патчи близко к верху.

В группах «backport» и «Не распростронять» патчи находятся в конце файла series. backport патчи должны применяться поверх всех других исправлений, также патчи из группы «Не распростронять» лучше держать от греха подальше.

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

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