Павел Емельянов, один из самых активных российских разработчиков ядра Linux, ответил на несколько вопросов opennet.ru, приуроченных к выходу (http://www.opennet.ru/opennews/art.shtml?num=34958) релиза CRIU 0.2 (http://criu.org/), системы для заморозки и восстановления состояния процессов в Linux. Последние шесть лет Павел работает в компании Parallels над проектами, связанными с изолированными контейнерами и облачными системами, в том числе является одним из основных разработчиков таких открытых проектов, как CRIU и OpenVZ (http://wiki.openvz.org).Расскажите как проходило становление участника разработки ядра Linux. Помните ли вы ваш первый коммит в ядро ?
Становление проходило труднее, чем, как мне сейчас видится, могло. Дело в том, что участвовать в разработке я стал сразу с нелегкой задачей - создание нового функционала. Кроме того, до меня из Parallels (тогда SWsoft) в mainstream слали не много патчей (да и были это, главным образом, устранения неисправностей), так что посоветоваться было не с кем.
Первый коммит уже помню, но это был какой-то очень простой патч, чинивший очевидную ошибку, так что прошел он незаметно.
Как был преодолён языковой барьер или у вас изначально было отличное знание английского ? Были ли языковые казусы ?
Если речь идет о письменном английском, то барьера не было, так как до этого я уже больше года работал в SWsoft, а там вся техническая переписка велаcь на английском (впрочем, для Parallels это некие корпоративные стандарты). Когда начал ездить на конференции, говорил, конечно, с трудом.
Разговорился, наверное, после третьей или четвертой поездки. А казусы были однотипные - я ничего не понимал, что мне говорят, и постоянно переспрашивал.
Как проходит продвижение патчей, какие подводные камни возникают ?
Это очень обширная тема. Можно даже целую статью на нее писать в журнал какой-нибудь :) Но если коротко охарактеризовать
- надо сразу настроиться, что разработка ядра это не технический процесс, а социально-технический, и одними "непробиваемыми аргументами" процесс двигать будет очень тяжело. Надо обязательно социализироваться, начать дружить с людьми из сообщества и делать это офф-лайн.
С кем приходится контактировать в цепочке продвижения патчей ?
Ну, "цепочка" это громко сказано. Обычно цель патча - это репозиторий ответственного человека (майнтейнера). Пока туда патч не попадет, контактируешь с ним и с другими обитателями тематического списка рассылки.
Возникают ли проблемы со стилем оформления кода ? Бывает ли, что не принимают патчи по идеологическим или формальным причинам ? Как удаётся приходить к компромиссу ?
Со стилем уже не бывает. Хороший текстовый редактор все делает за меня :) По идеологическим причинам не принимают довольно часто, особенно, когда это патч, который открывает "новое направление" в ядре. Тут приходится попотеть и попереписываться. К компромиссу приходят одним путем - это называется "progress by argument". Ты объясняешь, какой цели ты хочешь добиться и почему так, как это написано в патче. Если кто-то с тобой не согласен, он объясняет почему, и как сделать по-другому. Обычно один из вас объективно не прав, и в диалоге выясняется кто.
Какие наиболее важные подсистемы/патчи, в создании которых вы принимали участие, удалось продвинуть в основное ядро Linux ? Какие из подобных подсистем пока остаются непринятыми в ядро и что мешает их принятию ?
Все, что я делал, уже там в том или ином виде. Из самых крупных - виртуализация сетевого стека и PID-ов (идентификаторов процессов) и контроллер памяти приложений (a.k.a. memcg). Ну и, конечно же, главный мой проект сейчас - checkpoint-restore in userspace. Для него модифицируется во всех подсистемах по-немногу (но в сумме набралось уже почти 100 патчей). Непринятых в смысле принципиально отвергаемых сейчас нет, есть патчи, которые пока плавают в списках рассылки, ждут своей очереди на обсуждение или переработку.
Какой примерно объем работы приходится выполнять для синхронизации с новыми версиями ядра параллельно поддерживаемых патчей, которые ещё не приняты в основное ядро, для OpenVZ и CRIU ? Были ли особенно тяжёлые случаи, когда какое-то изменение в ядре серьёзно все ломало или заставляло пересматривать архитектуру ?
Для criu мы не перебазируемся в привычном смысле этого слова, так как проект изначально разрабатывается в mainstream. То есть - если что-то сообщество не берет, мы это и к себе не берем, а сразу переделываем.
Для OpenVZ патч для переезда, конечно, огромный. Перебазировались по-крупному мы уже 2 раза (с 2.6.9 на 2.6.18 и потом на 2.6.32), сейчас начинаем на 3.6. Переезд у меня занимал около месяца до состояния "готово к отдаче в QA". После этого еще пол-года на стабилизацию.
Случай, когда что-то серьезно архитектурно ломалось был один - это живая миграция. Сообщество наотрез отказывалось принимать эту технологию как большую ядерную подсистему. Результатом этого стал проект criu (criu.org).
Чего не хватает в штатном ядре для полноценной реализации CRIU ? Какие есть идеи по дальнейшему развитию CRIU ?
Если не брать мелочи, то самое большое белое пятно это memory snapshot. Технология, при которой мы говорим ядру, что хотим знать, какие страницы памяти меняются приложением в процессе его работы, и начинаем параллельно с выполнением процессом своих дел копировать его память. Потом замораживаем его и копируем только то, что он поменял. Это сильно сокращает время миграции и открывает возможность для такой фичи, как incremental snapshot состояния, при котором повторное снятие производится быстрее (гораздо быстрее) и можно делать его чаще.
Кроме того, есть очень большое желание нарастить вокруг criu свое сообщество разработчиков, так как вещей, которые с его помощью можно делать масса, но собственных сил внутри Parallels на все нет.
В каких ещё открытых проектах, кроме ядра Linux и продуктов Parallels, приходилось заниматься?
По-крупному ни в каких. Linux kernel + OpenVZ + CRIU (плюс закрытые продукты Parallels) пока с лихвой покрывают области моих интересов.
Какой дистрибутив и десктоп окружение используйте для работы и дома ? Какой инструментарий разработки предпочитаете (в чем пишите и отлаживайте код) ?
На ноутбуке Fedora + FluxBox, оно же дома. Инструментарий для работы и отладки сначала был простой - vim + дизассемблер + голова ;) чуть позже появилась еще команда. У нас в kernel team собрались очень талантливые люди, они знают и умеют гораздо больше меня, чем я и пользуюсь (в хорошем смысле этого слова).
Работайте ли дома в своё удовольствие или ограничивайтесь только рабочим временем ? Даёт ли работодатель возможность заниматься в рабочее время сторонними открытыми проектами (например, в Google можно тратить 20% своего времени на любые интересные проекты) ?
Для меня "рабочее время" очень размыто определено. У меня нет строгих часов, когда мне надо быть в офисе, чем я активно пользуюсь и крою свой день очень сильно. С другой стороны, когда возникает необходимость или желание, я часто что-то делаю из дома.
Заниматься своими проектами в рабочее время в Parallels, строго говоря, нельзя. Но с другой стороны, в Parallels работают очень открытые люди, так что если "свой проект" имеет отношение к деятельности компании, то можно (и даже нужно) поговорить со своим руководителем, и если проект действительно хороший, то у него огромные шансы стать частью продуктов Parallels. Или даже стать самостоятельным новым продуктом ;)
В каком году вы впервые столкнулись с Linux и когда стали использовать его вплотную ? Какой был ваш первый дистрибутив ?
С Linux столкнулся в институте на 2-м курсе. У нас в программе была тема про UNIX, а практика была на Linux.
Первым дистрибутивом стал ASP-linux, так как на то время это был единственный дистрибутив с нормальной поддержкой русского языка. Не в интерфейсах - с этим проблем не было - п...
URL:
Новость: http://www.opennet.ru/opennews/art.shtml?num=35028
