В этом году Xorg, свободной реализации X Window System, исполняется 30 лет. Несмотря на существование и развитие альтернатив Xorg остаётся живее всех живых.
По случаю юбилея я задал несколько вопросов человеку, который 23(!) года работает над развитием этого проекта. Зовут его Matthieu Herrb. Помимо своего участия в проекте X.Org он также стоит у истоков создания отдельной версии Xorg для проекта OpenBSD — Xenocara.
X.Org это большой и сложный проект. Как выглядит процесс разработки?
Проект не такой большой, по сравнению с другими проектами, наподобие Firefox, Chrome или даже Gnome или KDE.
Процесс разработки немного отличается для разных наиболее активно разрабатываемых компонентов (сам X сервер, немного библиотек и драйвера) и устаревшие компоненты, наподобие libXt и все приложения, основанные на этой библиотеке.
Также есть постоянное взаимодействие между двумя группами: это разработчики Mesa и DRM модулей в Linux ядре.
Идеи обсуждаются во время встреч разработчиков (один раз в год, в Европе или Северной Америке, следующий будет в сентябре этого года в Бордо, Франция) или в почтовом списке рассылки xorg-devel.
Последние несколько лет мы адаптировали модель разработки, которая очень похожа на модель разработки Linux ядра: патчи (сформированные с помощью git format-patch) посылаются в список рассылки для ревью, проводится обсуждение и, если достигнута договоренность в обсуждении, то патч комиттится мейнтейнером.
Существует один мейнтейнер для X сервера (в данный момент это Кейт Пакард). Для других компонентов приём коммитов более простой и как правило автору патча, чтобы and it's generally the author of a patch that pushes it once it has been reviewed positively.
И, чтобы быть полным, в настоящее время развитие популярных драйверов почти полностью возложено на компании (Intel, AMD, VMWare), так что инженеры из этих компаний делают большинство изменений.
Сколько разработчиков вовлечено в процесс разработки?
Если считать разарботчиков Mesa, графический стек в ядре Linux и разработчиков X сервера, то это порядка 50-60 человек кто комиттит на постоянной основе в один из репозиториев.
Как выглядит процесс тестирования? Вы используете регулярное тестирование (запуск тестов на каждый коммит) или это нерегулярное тестирование?
У нас есть несколько инструментов для постоянного, автоматизированного тестирования, но они не эфективны настолько насколько нам хотелось бы.
Какие инструменты, тесты и тестовые фреймворки вы используете? Я нашел много тестов (например XTS, rendercheck, glean, piglit и т.д.) в репозитории (http://cgit.freedesktop.org/), но многие из них выглядят устаревшими. Создают ли разработчики тесты на регулярной основе для нового функционала и на основе багфиксов?
Вдобавок ко всем этим существующим тестсьютам, которые обычно очень громоздкие для использования на регулярной основе, Peter Hutterer разработал относительно новый, интеграционный тестсьют для X сервера, который предполагается запускать автоматически из билдовой системы X сервера (с помощью 'make test') и на нашем сервере с Tinderbox. Скрипт build.sh используемый многими разработчиками также запускает эти тесты по умолчанию.
Но учитывая огромный спектр поддерживаемых систем (хотя со времени переключения с XFree86 на X.Org это число постоянно сокращается) только небольшая часть из них получает фактическое регулярное тестирование.
Большинство тестов сделано людьми, которые интегрируют X.Org в другие системы и дистрибутивы.
Это мой случай среди других. Я поддерживаю X.Org в OpenBSD (и помогал в NetBSD раньше), так что я тестирую конфигурации, которые не охватываются основными разработчиками X сервера и часто нахожу ошибки, которые пропускаются в процессе тестирования, либо потому, что они специфичны для платформы (например, OpenBSD является одной из нескольких систем, которые по-прежнему работают на некоторых экзотических архитектурах, таких как VAX, m88k или даже sparc32), или просто потому, что наша реализация malloc() способна поймать ошибки, которые ускользают от других инструментов используемых в Linux.
Какие виды тестирования используются (тестирование производительности, функциональное, тестирование на совместимость, тестирование стабильности, юнит тестирование и т.д.)?
Новый тестовый фреймворк для X сервера в основном использует юнит-тестирование и функциональное тестирование, чтобы убедиться, что компоненты X сервера работают the way they are supposed to in a driver independent manner.
В случае использования тестов вы измеряете покрытие кода тестами?
Нет. Так как чаще всего код и тесты пишет один и тот же человек, то он имеет некоторое понимание о покрытии этого кода,
но нет какого-то формального инструмента для измерения покрытия.
Как часто вы тестируете: время от времени или на регулярной основе?
Платформа Tinderbox предполагалась для запуска тестов настолько часто как это возможно, но большинство других тестов запускаются вручную время от времени.
Как тестируются новые фичи?
Новые возможности в X, ты шутишь, да? А если серьезно, то были добавлено некоторое количество новых фич в основном в Mesa (OpenGL) код и драйвер ввода. Либо новые тесты для фич добавляются в тестсьют одновременно с самим кодом, или, в случае с OpenGL, используются внешние проверки соответствия.
Вы используете Continuous Integration в процессе разработки?
Да, я упомянул уже несколько раз Tinderbox, хотя это далеко от совершенства.
Какой инструмент вы используете для работы с дефектами? Кто ответственный за работу с багами?
У нас есть Багзилла, дополненная системой отслеживания патчей (patchwork) которая отслеживает, что не осталось незакомиченных патчей that no submitted patch gets forgotten or unhandled.
Иногда в X.Org находят проблемы связанные с безопасностью (http://www.x.org/wiki/Development/Security/). Вы используете регулярный аудит кода?
И да и нет :) Насколько я знаю X.Org не имеет выделенного человека для аудита на регулярной основе. Но некоторые дистрибутивы (например Oracle/Solaris в лице Alan Coopersmith) регулярно используют инструменты ориентированные на выявление проблем с безопасностью и вносят исправления в проект. Иногда, когда появляется конкретный новый вид уязвимости (как например форматирование строк или целочисленного переполнения около 10 лет назад), то мы делаем огромный чистку существующиго кода, чтобы попытаться всё в нём исправить.
Мы также получаем внешнюю помощь от независимых исследователей в области безопасности, которые следят за любопытными уязвимостями, и так как X-сервер всё ещё запускается с правами суперпользователя на многих системах, это все ещё оправданно.
Последний год Ilja Van Sprundel отрепортил очень большое количество уязвимостей в бибилиотеках X сервера и в самом X сервере, в основном касающиеся отсутствием хорошей валидации сообщений в протоколе X сервера.
Вы применяете статический анализ кода?
Ответ похож на мой предыдущий. Tinderbox не запускает никакие статические анализаторы кроме gcc с опцией -Wall и еще некоторых дополнительных опций. Но у некоторых разработчиков (включая Алана из Oracle) есть доступ к мощным статическим анализаторам кода и они запускают их время от времени.
Coverity имеет программу для проведения статического анализа свободных огранизациях. X.Org был частью этой программы и они помогли нам найти ряд проблем.
X.Org поддерживает все более менее популярные операционные системы: Linux, FreeBSD, NetBSD, OpenBSD, Solaris, Microsoft Windows. Как вы обеспечиваете уверенность в стабильной работе на всех этих ОС?
Как я объяснил выше это обеспечивается волонтёрами (или оплачиваемыми работниками в некоторых случая) из различных проектов. Большинство разработчиков фокусируется на Linux, который стал основной платформой разработки в последние 10 лет. Но от себя хочу добавить, что мне немного жаль, что разработчики не вмешиваются чуть больше в поддержку на других системах. Из моего опыта нужно много изучить для разработки на больше чем одной платформе и с точки зрения безопасности кода разнообразие имеет большое значение (даже если это увеличивает стоимость разработки).
Кто ответственный за выпуск новых версий? Какие критерии для релиза?
Существует мейнтейнер для X сервера, который ответственен за выпуск релиза. В данный момент мы работаем в 6-тимесячном цикле разработки для выпуска нового релиза каждые 6 месяцев. Предыдущий релиз получает -stable мейнтейнера и в основном поддерживается в течение более 12 месяцев.
В дополнение к релизам X Server мы до сих пор выпускаем релизы «Katamari»
с полным последовательным набором библиотек и утилит в дополнение к
X-серверу. Это делается один или несколько раз в год. (текущим релизом «Katamari» является
7.7, на основе X сервера 1.14). Но потребность в релизах «Katamari»
часто ставится под сомнение, так как производители дистрибутивов, как правило, поддерживают
свои собственные «Katamari» (с большим количеством мёрджей из upstream), независимо от официальных, выпускаемых X.Org.
Времена, когда проект XFree86 предоставлял бинарные сборки для большинство поддерживаемых систем (от SVR4 до Linux, включая NetBSD, OS/2 и несколько других), безусловно, закончились.
Расскажите о самом интересном баге в вашей практике. :)
Работа с кодом, который был спроектирован и реализован когда безопасность кода не имела большого значения, не так уж и интересна. X сервер был изначально permissive system (помните «xhost +»?). Люди не заботились о переполнении буфера или других злонамеренных путях эксплуатации ошибок кодирования. Фичи наподобие расширения X-SHM были сломаны изначально. (SHM был исправлен путём использования нового API, основанного на передаче файлового дескриптора).
Но наиболее интересная проблема, с моей точки зрения, описана в статье Loic Dufflot на CanSecWest 2006, где он объяснил, что даже с privelege escalation, который я добавил в OpenBSD, остаётся возможность «простого» внедрения кода для получения контроля над ядром ОС из-за того, что X сервер имеет прямой доступ к железу.
Это то, что всегда было известно (и я даже говорил об этом в своем докладе на RMLL в 2003 году), но отсутствие реализации PoC (Proof of Concept) позволяет многим разработчикам игнорировать проблему.
Спасибо за ответы и желаю вам меньше багов в коде!
Спасибо.
В заключение хочу добавить, что да, X.Org далёк от идеала с точки зрения тестирования. Мы пытаемся делать его лучше, но это не самая привлекательная область для контрибьюторов, вещи не делаются быстро, так как большинство разработчиков предпочитают более привлекательные вещи.
Автор: estet
