Материал из Linuxformat.

«Мне жаль, что Линус не использовал CVS с первого дня»

Официальный maintainer — хранитель ядра — рассказывает о процессе разработки и о необходимости улучшения контроля качества.

Мы встретились с главным разработчиком ядра 2.6, усадили его в большое надувное кресло и попросили ответить на наши вопросы. Фактически, Эндрю Мортон является вторым человеком (после Линуса Торвальдса, конечно), на котором держится весь процесс разработки ядра Linux, так что он оказал нам бесценную помощь в проникновении на главную кухню разработчиков. Мы увидели его на OSCon 2005 и поговорили о переходе с BitKeeper, исправлении ошибок и необходимости увеличения скорости работы ядер Linux.

LXF: Переход на BitKeeper раздражал многих людей, особенно из FSF. Потом был переход на Git… Не окажется ли Git всего лишь временным решением?

ЭМ: Нет, я думаю, что Git останется надолго.

LXF: Значит, Вы считаете, что Git практически вечен?

ЭМ: Я предполагаю, что да. Дело в том, что цена подобного перехода слишком высока и с лихвой перекрывает все возможные выгоды.

LXF: Не думаете ли Вы, что Git должен был появиться раньше, или что с самого начала следовало бы использовать CVS?

ЭМ: Ну, мы никогда не использовали CVS. Вернее, до BitKeeper мы вообще не пользовались подобными инструментами — просто была куча заплаток, которые хранились у Линуса на жестком диске, и иногда он включал их в ядро. Мы вообще никак не могли проследить, что туда попало. Помоему, это как-то не очень вежливо, и мне жаль, что Линус не использовал CVS с самого начала. Он ненавидит CVS, потому что имел с ним проблемы, однако я считаю, что для простой линейной модели развития использование CVS было оправдано, да и появилась бы история изменений.

Я думаю, главная заслуга BitKeeper — в том, что Линус вообще стал хоть чем-то пользоваться. При любой другой свободной системе контроля версий мы все равно прошли бы 90 % пути. Просто BitKeeper был тогда лучшей подобной системой и подходил под наш процесс разработки. Я и сам чувствовал себя некомфортно, используя BitKeeper — естественно, из-за его проприетарности, но с этим жить можно. В конце концов, моя главная задача — улучшение ядра, а не… э-э… религиозный фанатизм. Я всегда ждал, что конец будет плачевным и BitKeeper откинет колеса. Переход оказался более резким, чем я рассчитывал, но мы довольно легко вышли из неприятной ситуации.

LXF: Показал ли BitKeeper широкой общественности, как надо работать? Ведь благодаря ему Вы и перешли на Git, вместо того, чтобы вернуться к старой модели получения заплаток по электронной почте. Правда, что он создал такие преимущества, без которых люди теперь не могут обойтись?

ЭМ: Да, конечно, мы теперь не сможем жить без системы контроля версий и ни за что не вернемся к старой модели разработки, которая существовала до BitKeeper. Все очень оценили его удобства.

LXF: Наверняка ускорилось внедрение исправлений.

ЭМ: Так говорят… Скорее, это облегчило работу Линусу — система контроля версий позволяет ему доверять людям. Например, если Грег КроаХартман (Greg Kroah-Hartman) вышлет ему серию заплаток со словами «наложите, пожалуйста, их на ядро», то он просто поверит Грегу и сделает это. Раньше, когда у нас не было системы контроля версий, Линус тщательно вчитывался в каждую строку присланного кода — в итоге получилось косвенное улучшение производительности! Что бы мы ни использовали как систему контроля версий, необходимость перемен в ядре оказывает все более настоятельное давление. Появилось много новых талантливых разработчиков, уровень разработок растет, скорость изменений уже пробила крышу. Может, мы справились бы и без всяких систем контроля версий, но счастливы, что нам не нужно этого делать.

LXF: Вы сказали, что число разработчиков постоянно растет. Однако создается впечатление, что и журнал изменений в каждой новой версии все больше. Я просмотрел 2.6.2 (287К), 2.6.4 (322К), 2.6.6 (487К), 2.6.8 (883К), 2.6.10 (1.5МБ)…

ЭМ: Каждый новый журнал включает в себя все старые, но в общем это действительно так.

LXF: Это отражает повышение скорости разработки?

ЭМ: В некоторой степени да. Раньше выпуски появлялись один за другим, а в последнее время мы несколько снизили частоту. Но сама разработка медленнее не стала.

LXF: Я заметил, что в журнале изменений есть позиция «Signed off by» — «Подписано таким-то». Зачем это нужно?

ЭМ: Это своеобразный способ избавиться от «глупостей» SCO. Люди хотели иметь возможность разобраться, откуда взялись конкретные участки кода. Нам и самим, независимо от них, казалось, что неплохо бы знать, кто прислал «кривой» код. Таким образом, мы приняли простое соглашение: каждый, кто предложил какуюто заплатку, должен подписать ее своим прозвищем. «Подписано» значит, что автор читал «Сертификат об источнике» (Developer’s Certificate of Origin), который содержится в документации ядра, и согласен с ним.

LXF: Значит, эта надпись говорит не о качестве кода, а лишь сообщает, что

«я верю, они это сами написали»? ЭМ: Да, так и есть. Эта надпись говорит «я написал этот код сам, я подтверждаю, что не стырил его из какой-нибудь UnixWare или другой системы». И каждый, кто присылает заплатки, обычно добавляет подобную подпись. Есть еще гриф «Ackd by».

LXF: А это что значит?

ЭМ: Это значит «Одобрено», для случаев, когда кто-то просто проверил чей-то код, но ничего в нем не менял. Вообще-то это предназначено для хранителей-maintainer’ов, которые хотят подчеркнуть, что заплатка проверена.

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

ЭМ: Да, так оно и было. LXF: Теперь же есть двухнедельное «окно», в ядро включается только то, что было дописано, что готово на данный момент. ЭМ: Ох, тут моя вина. Я выступил с речью насчет этого на встрече разработчиков ядра. Я не считаю, что на сегодняшний день качество кода ядра стоит на должной высоте. В каждой новой версии приходится возвращаться к ошибкам прошлых. Предполагалась такая модель: в день, когда Линус решает выпустить новую версию, все хранители подсистем, а их 50-70 человек, принимаются включать весь накопившийся материал, причем в идеале обязаны уложиться в недельный срок (самая активная бомбежка заплатками происходит в первую неделю после выпуска). Еще неделю я сливаю все заплатки в свое дерево, и следующие четыре недели мы стабилизируем изменения, отлавливаем ошибки и так далее. Пока мы этим занимаемся, люди работают над новым функционалом для следующего цикла. В общем, это похоже на конвейер. Так было задумано. Фактически же, люди непрерывно присылают что-то новое. В прошлый раз, например, нам пришлось капитально обновлять аудиодрайвер спустя всего четыре недели после выпуска 2.6.12. И все из-за плохой синхронизации, потому что здоровенный кусок кода куда-то потерялся за то время, когда шла проверка стабильности. Мы хотим, чтобы хранители подсистем работали в более тесной связке с разработчиками ядра.

LXF: Вы сказали, что скорость разработки ядра постоянно растет, а по моим наблюдениям, промежуток времени между выходом новых версий ядра увеличивается. Может быть, развелось слишком много хранителей ядра, которые почем зря закидывают вас заплатками?

ЭМ: Главное, слишком много кода - время уходит на его проверку, доработку, тестирование. Бывает, большие куски кода доходят с опозданием: если доработанная SCSI-подсистема попадает к нам на 5-й неделе, мы не в состоянии выпустить устойчивое ядро со всеми изменениями, уложившись в график. Нужно же все «обкатать»!

LXF: У Вас существует плановая периодичность выпуска ядра?

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

LXF: Когда Торвальдс объявил, что будет работать на PowerPC, он назвал Power 5 и ЭМD64 двумя самыми перспективными архитектурами. Вы согласны с этим заявлением?

ЭМ: Ну, в общем, x86 уже не тот, что раньше; а вот c x86-64 все хорошо. Люди просто принимают слишком близко к сердцу, какая именно машина в данный момент у Линуса на столе. Я не думаю, что это так важно. У него хватает компьютеров x86 для тестирования.

LXF: Он теперь переехал в Портленд — наверное, тяжело жить так далеко от него, по сравнению с былыми днями?

ЭМ: Фактически, мы жили на расстоянии 20 минут: он — в Сан-Хосе, а я - в Пало-Альто. А лично встречались тогда всего два раза.

LXF: Если говорить о вещах, которые сейчас на слуху, вроде Xen или Inotify — Вы находите их интересными?

ЭМ: Ну, Xen, очевидно, очень нужен многим. Я не склонен что-либо предусматривать только потому, что люди нам это присылают. Принятие решения о нововведениях в ядро происходит коллегиально. Мы с Линусом не бросаем клич вроде «Эй, нам нужны x, y и z в третьем квартале 2006-го года».

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

А что в будущем? [напомним, интервью бралось на конференции OSCon осенью 2005 года, — прим.ред.] FUSE мы скоро поместим, очень многим это понравится. Кластерную файловую систему OCFS планируем включить в ядро 2.6.14. Кластеры — довольно обширная тема, мы потратили на нее много лет.

Существует масса кластерных проектов, но все они слишком разные, и их разработчики никак не могут найти точек соприкосновения и договориться. OCFS же выглядит готовым решением, и нет никаких препятствий включению его в ядро. Я отнюдь не уверен, что со штуками вроде Red Hat GFS будет так же легко. Ну что еще.. не знаю, что вам сказать. Какие нам коды люди пришлют, такие и будем внедрять.

LXF: Как долго код из Вашего mmдерева добирается до официальной версии ядра Линуса?

ЭМ: Всякое бывает. По большому счету, мой код и есть то самое ядро, которое выйдет через несколько месяцев, за вычетом определенных кусков. Я вставляю в него всевозможные заплатки, тестирую, и, возможно, отсылаю Линусу, когда считаю, что все готово. Естественно, расхождения накапливаются. Например, на сегодняшний день в моем ядре есть файловая система Reiser4, это около 2-х мегабайт, и несколько других интересных функций. Они не влияют на идеологию ядра, просто добавляют какие-то функции, но это большие куски кода.

LXF: Над чем лично вы сейчас работаете? Например, вы еще используете какой-нибудь DDE?

ЭМ: Боюсь, что да. Я давненько не занимался пользовательским пространством, вожусь с дурацким скриптом управления патчами.

LXF: Вы тратите 12-14 часов в сутки на работу с ядром?

ЭМ: Да, тестирую новые патчи, исправляю ошибки и т. д. Связываюсь с другими разработчиками. На борьбу с ошибками уходит довольно много времени.

LXF: На исправление ошибок?

ЭМ: Скорее, на выяснение информации об ошибке. Иногда отчеты об ошибке (а это очень ценная вещь) присылаются довольно бестолковые — приходится вступать в диалог с отправителем, чтобы разобраться. Причем я всегда стараюсь найти автора проблемного кода. Вот прямо сейчас мы работаем над rc5 ядра, где ничего особенного добавлено не было — сплошные исправления ошибок.

LXF: Таким образом, это почти маркетинг ошибок, их пропаганда…

ЭМ: До известной степени да, равно как и социальная инженерия.

LXF: Так получается потому, что некоторые хранители поддерживают свои части ядра лишь из уважения к Вам?

ЭМ: Ну, порой этих хранителей приходится стыдить. Хотя вообще-то надо бы им посочувствовать. Большинство сбоев возникает на уровне драйверов, и хранители не могут воспроизвести их. Вот основная проблема. Поэтому приходится долго и сложно вести переговоры с человеком, который сообщил про данный сбой, разбираться, что именно произошло, просить его ставить на заплатку другие заплатки и выполнять одно, другое, третье… Получается удаленная отладка. Хлопот немало.

LXF: Кроме ядра, есть ли другие проекты, которые Вам интересны и над которыми Вы хотели бы работать?

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

LXF: Вы сейчас на «острие прогресса» ядра. Когда появится версия 2.7, будете ли Вы продолжать развивать линейку 2.6, или передадите ее кому-нибудь другому, а сами будете готовить 2.8?

ЭМ: Поживем — увидим. Многое будет зависеть от причин для выпуска 2.7; я пока не представляю, какими они будут. Одна из возможных причин - неудовлетворенность качеством ядер 2.6. Но я думаю, что ветви 2.6 еще есть куда расти.

LXF: Что Вы намерены делать дальше?

ЭМ: Вероятно, я в том или ином качестве буду работать над Linux — скорее всего, до конца своей карьеры.