Расширенное использование

Mercurial Queues

•Группа «в процессе разработки». Патчи, которые активно развиваются, и не должны быть представлены еще нигде.

•Группа «backport». Патчи, которые адаптированные для дерева исходных текстов с более старыми версиями ядра.

•Группа «Не распростронять». Патчи, которые почему-то никогда не должны быть представлены в апстриме. Например, один такой патч может изменить встроенный идентификатор драйвера, чтобы было легче различать, области, между версией драйвера вне дерева и версией распространяемой поставщиками.

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

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

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

13.8. Поддержка серии патчей

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

•accepted защищает «принятые» патчи. Я включаю эту охрану большую часть времени. Когда я применяю патчи поверх дерева, где эти патчи уже есть, я отключаю эти патчи, и следующие за ними применяются чисто.

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

•Те, патчи, которые требуют доработки, прежде чем вновь отправится охраняются с помощью rework.

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

•backport патчи имеют различных охранников, по одному для каждой версии ядра, к которому они относятся. Например, backports патча у кода ядра 2.6.9 будет охранник 2.6.9.

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

13.8.1. Искусство писать backport патчи

Использование MQ, для написания backport патчей простой процесс. Все что нужно сделать в патче, это изменить фрагмент кода, который использует функции ядра которой нет в старой версии ядра, так что драйвер продолжает работать правильно в соответствии с этой старой версией.

Полезная цель при написании хорошего backport патча это сделать код выглядящим так, будто он была написан для старой версии ядра, на которую вы ориентируетесь. Чем менее навязчив патч, тем легче будет его понять и поддерживать. Если вы пишете коллекцию backport патчей, чтобы избежать эффекта «крысиного гнезда» — большого количества #ifdefs (блоков исходного кода, которые будут использоваться только условно) в коде, не вводите зависимые от версии #ifdefs в патчи. Вместо этого, напишите несколько патчей, каждый из которых дает безусловные изменения, а также контролируйте их примеением с помощью охранников.

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

160