ROS Newsletter80

Выпуск новостей ReactOS №80

• Публикация в архиве

Тестирование компонентов

В ReactOS добавляется всё больше и больше компонентов, предназначенных для обеспечения поддержки файловых систем, и их необходимо тестировать. Для облегчения тестирования Пьер Швейцер (Pierre Schweitzer) попытался воспользоваться драйвером FASTFAT от Microsoft, поскольку его корректная работа в ReactOS станет верным признаком правильного направления разработки. К сожалению, из этой попытки ничего не вышло, поскольку текущее состояние диспетчера кэша в ReactOS крайне плачевно. В предыдущих выпусках мы уже упоминали о диспетчере кэша и его проблемах. Арт Йеркс (Art Yerkes) недавно написал код новой реализации диспетчера, но к настоящему моменту его функциональность крайне ограничена, и потребуется ещё больше работы для того, чтобы он смог заменить имеющуюся на данный момент реализацию диспетчера кэша в ReactOS. Одна интересная, или скорее даже удивительная проблема состоит в том, как по крайней мере одна из функций в текущей реализации диспетчера, по всей видимости, игнорирует предоставляемую ей информацию об объёме данных при необходимости прочитать что-либо. Вместо этого она использует данные о размере читаемого ей файла. Обратите внимание, что понятия "размер файла" и "объём данных" здесь не равнозначны, поскольку диспетчеру не всегда нужно читать весь файл, чаще всего необходимо прочитать только его часть. Похоже, что именно по этой причине драйвер Microsoft пытается прочитать данные в блок нулевой длины, что и вызывает сбои в работе текущей реализации диспетчера.

До сих пор Пьер достиг успехов лишь в попытках заставить драйвер успешно инициализироваться, что позволяет протестировать лишь очень малую часть FsRtl. Из-за плохого состояния текущего диспетчера кэша, Пьер начал экспериментировать с новой его реализацией, созданной Артом. Хотя поддержка драйвера всё улучшается и улучшается, в новом диспетчере ещё имеется достаточно ошибок и недостающей функциональности, из-за которых драйвер сталкивается с множеством проблем при своей работе. Похоже, что из-за одной из таких проблем не происходит понижение уровня запроса на прерывание перед выполнением некоторых операций, таких например, как доступ к памяти компьютера. Однако не факт, что эта проблема вызвана новым диспетчером кэша, возможно, она указывает на более глубокие проблемы в ядре системы.

Ещё одна проблема, обнаруженная Пьером и исправленная Алексеем Брагиным, находилась в диспетчере ввода/вывода. Всего существует два типа операций ввода/вывода - синхронные и асинхронные. При синхронных операциях инициатор операции дожидается её завершения. При асинхронных операциях инициатор операции может заниматься другими задачами, а по завершении операций он получит об этом соответствующее уведомление. Запросы ввода/вывода представляются пакетами ввода/вывода (IRP), в которых имеется специальный флаг, указывающий на тип запроса (синхронный или асинхронный). Однако, если IRP запрашивает операцию ввода/вывода из страничной памяти, то операция всегда будет асинхронной, за исключением случаев, когда установлен флаг IRP_SYNCHRONOUS_PAGING_IO. Существуют и другие флаги, используемые в IRP для обозначения синхронных операций, но в случае доступа к памяти при определении типа операции учитывается только этот флаг. Диспетчер ввода/вывода в ReactOS не следует этой концепции, и поэтому некорректно помечает операции ввода/вывода из страничной памяти как синхронные и возвращает неправильные коды статуса. Когда драйвер FAT от Microsoft обнаруживает этот неправильный код статуса, происходит сбой, который и наблюдает Пьер.

Оптимизации и исправления в ARWINSS

В архитектуре ARWINSS имеются некоторые особенности, которые могут показаться неэффективными или избыточными. Одной из таких особенностей является дублирование таблиц описателей в режиме ядра подсистемы Win32k и в модулях пользовательского режима Wine. Чтобы гарантировать надлежащую взаимосовместимость, эти две таблицы необходимо синхронизировать. Изначально, эта синхронизация происходила на уровне ядра подсистемы Win32k, что требовало ресурсоёмкого перехода в режим ядра каждый раз, когда приложению, находящемуся в пользовательском режиме, необходимо было прочитать таблицу описателей, поэтому Алексей Брагин переместил код синхронизации в драйвер пользовательского режима winent. Это не помеха для Win32k, поскольку код в режиме ядра имеет доступ ко всем данным, находящимся в пользовательском режиме, зато операции в пользовательском режиме смогут отложить ресурсоёмкое переключение режима, производя запись данных в память в пользовательском режиме. Это не идеальное решение (по сравнению с наличием только одной таблицы), но Яннис Адамопулос (Giannis Adamopoulos) уже начал работу над внедрением в ARWNSS разделяемой памяти, которая сделает возможной полностью корректную реализацию.

В Wine никогда не было необходимости в высокоуровневом управлении окнами, поскольку в Unix имеется окружение X Window, которое берёт эту задачу на себя. Однако подсистема Win32 в ARWINSS вынуждена этим заниматься. Ситуация усложняется ещё и перекладыванием на неё дополнительной ответственности. Необходимо помнить, что в ReactOS уже существует подсистема Win32, имеющая свои собственные характеристики входных и выходных данных, не совместимые с Wine. Следствием этого являются проблемы с правильной прорисовкой и очисткой экрана при перемещении окон. Алексей устранил некоторые проблемы и продолжает работать над другими, но правильный расчёт видимости окна при наличии двух различных типов поведения кода является крайне непростой задачей.

Инфраструктура автоматической сборки ReactOS

Колин Финк (Colin Finck) и Олаф Сейка (Olaf Siejka) работали над обновлением систем для сборки и тестирования ReactOS. В настоящее время ведутся работы по реализации поддержки портов ReactOS для архитектур ARM и x64, а также по переходу на CMake и поддержке совестимости с MSVC. На данный момент успешно удалось собрать и протестировать только транк, однако возможность автоматической сборки и тестирования других ветвей была бы также чрезвычайно полезна. Олаф уже настроил свою собственную машину для сборки под управлением Windows с последним набором обновлений, и добавил её как ведомое устройство сборки к набору машин команды. Также был введён новый пользовательский интерфейс, позволяющий разработчикам и некоторым из тестеров упростить подачу запросов на сборку определённых ревизий. Учитывая мощность некоторых из машин, наличие доступа к таким системам поможет значительно ускорить процесс регресс-тестирования.

Предстоящие события

Пьер Швейцер представит ReactOS в своём учебном заведении, l'Institut Supérieur d'Informatique, de Modélisation et de leurs Applications (ISIMA), расположенном в городе Клермон-Ферран, Франция, 17 Февраля в 13:30 местного времени. Там он вместе с Сильвейном Петреолле (Sylvain Petreolle) будет рассказывать как о технических аспектах ReactOS, так и о некоторых исторических. Если у вас есть возможность, приходите и поучаствуйте.

Колин Финк, Тимо Кройцер, Маттиас Купфер, Даниэль Раймер и Кристоф фон Виттих, то есть в основном немецкий состав команды ReactOS, вновь посетят конференцию Chemnitzer Linux–Tage в Хемнице, Германия. Они присоединятся к Каю Тиецу (Kai Tietz), разработчику проекта Mingw-w64, с которым ReactOS взаимодействует по вопросам добавления дополнительных возможностей в компиляторы и среду сборки, и смогут вновь его поприветствовать.

И наконец, Виктор Мартинес (Victor Martinez) расскажет о ReactOS на IV Jornadas Tecnológicas de Isla Cristina, которое пройдет с 31 марта по 1 апреля. Мероприятие будет проводиться на Исла-Кристина-Уэльва, Испания.

Подписывание кода драйвера

Некоторое время назад было объявлено, что Фонд ReactOS получил от VeriSign сертификат для подписывания кода, позволяющий нам подписывать драйверы, что позволит обеспечить их работу на 64-х битных системах семейства Windows без "танцев с бубном" и необходимости отключения значительного количества медиа-компонентов. Фонд также выразил готовность подписать драйверы Windows других проектов с открытым кодом, которые не могут получить сертификат из-за его высокой стоимости. Условия для подписывания кода в настоящее время получили официальный статус и перечислены на этой странице. Основным моментом является то, что Фонд не станет рисковать и не станет подписывать код, из-за которого сертификат может быть отозван, таким образом, никакой код, разработанный с целью обхода средств защиты ОС или DRM не будет нами подписан. Мы также просим объяснения всех спорных вопросов, выявленных при проверке драйвера. Помимо всего прочего, если код удовлетворяет всем условиям, то нашим требованием также является то, чтобы проект находился под свободной лицензией или лицензией с открытым исходным кодом, а на сайте проекта, драйвер которого мы подписываем, имелась ссылка на проект ReactOS.