ROS Newsletter74

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

• Публикация на сайте проекта

Общая информация

Усилия Амина Хальди (Amine Khaldi) по чистке заголовков драйверов наконец начинают давать результаты. Помимо того, что большая часть заголовков драйверов была приведена в порядок, были добавлены необходимые проверки, позволившие использовать заголовки драйверов как в MSVC, так и в GCC. Тот, кому приходилось писать кроссплатформенный код, должен знать, что синтаксис этих двух компиляторов имеет небольшие отличия, так что создать код, работающий с ними обоими, можно очень быстро. Работа Амина позволяет облегчить интеграцию некоторых новых драйверов, а также устранить некоторые ошибки при компиляции ядра ReactOS для процессоров ARM.

Команда поддержки сайта ReactOS занимается изучением причины проблем с DNS сайта и программным обеспечением сервера для автоматической сборки. На данный момент проблема с DNS, кажется, решена, и сайт снова доступен по его доменному имени. Однако на сервере, на котором производится сборка, возникали неполадки с процессорами и скорее всего потребуется некоторое время, чтобы привести его в порядок. Тестеры объединились и создали временную систему для своих целей, так что тесты на регрессии всё ещё работают. Неисправность сервера позволила Олафу Сейке (Olaf Siejka), одному из главных тестеров, проверить замену системе оповещения о новых сборках и общей поддержки IRC-канала ReactOS.

Yarotows

Это аббревиатура для Yet Another Rewrite of the Old Win32 Subsystem (пер. "ещё одна попытка переписать cтарую подсистему Win32") - весьма соответствующее название для ветви, над которой на протяжении последних нескольких месяцев работают Жером Гардо (Jérôme Gardou) и Тимо Кройцер (Timo Kreuzer). То, что Тимо начал как попытку переписать способ загрузки драйверов дисплея подсистемой Win32, переросло в большой проект по исправлению основных проблем в реализации подсистемы. Из-за этих проблем в ReactOS невозможно выполнить некоторые элементарные вещи, например изменить разрешение экрана и глубину цвета без перезагрузки. Во многих отношениях Yarotows является ответом ветке ARWINSS, созданным несколькими разработчиками, скептически относящимися к ней, но крайне сложно разрешить проблемы, имеющихся в win32k, при этом не вызвав проблем в транке, поэтому от серьёзных манипуляций с транком пришлось отказаться. Однако в ветви разработчики могут абсолютно спокойно делать всё, что необходимо для решения некоторых старых проблем в архитектуре ReactOS.

В Windows для описания всех имеющихся аппаратных адаптеров используется структура данных GRAPHICS_DEVICE. Адаптеры могут поддерживать разные режимы вывода изображения с использованием различных технологий, которые доступны через драйверы дисплея, перечисленные в структуре GRAPHICS_DEVICE. Драйверы дисплея в системе представлены логическим объектом устройства (LDEVOBJ), в котором перечислены все режимы, поддерживаемые данным конкретным драйвером. Существует также физический объект устройства (PDEVOBJ), представляющий текущий используемый режим и создающий поверхность, на которую выводит изображение драйвер дисплея. Когда подсистема Win32 запускается, она проверяет системный реестр на предмет имеющихся устройств и создаёт объект GRAPHICS_DEVICE для каждого из них. Затем выбирается режим и загружаются соответствующие LDEVOBJ и PDEVOBJ. Однако, подсистема Win32 в транке не имеет реализации структуры LDEVOBJ, что делает механизм её загрузки абсолютно неправильным с точки зрения архитектуры, а также приводит к неспособности переключаться между различными режимами дисплея без перезагрузки, так как за доступными режимами должен следить именно LDEVOBJ. Необходимо было написать "с нуля" весь механизм загрузки драйверов, что само по себе крайне сложная задача, и, разумеется, её осуществление привело к многочисленным ошибкам и регрессиям. Однако, имея в системе реализацию различных объектов, мы приблизились ещё на один шаг к возможности изменения режима экрана без перезагрузки.

Разработка правильной архитектуры загрузки драйвера закончилась тем, что обнаружилось несколько ошибок, которые никогда не выявлялись, так как работа над переключением режимов никогда не была первоочередной. К счастью, MSDN послужила в качестве полезного справочного материала для исправления недостатков, поскольку там содержится подробное описание работы этого механизма. Первая проблема касалась доступа к поверхности для вывода изображения. При создании изображения на поверхности крайне необходимо управлять доступом к ней, поскольку разрешив двум различным объектам вывод на поверхность в одно время, можно вызвать серьёзные проблемы. Изменение режима во время того, когда какой-либо объект занят выводом изображения на поверхность, также может привести к отрицательным результатам, так как свойства поверхности могут измениться. В предыдущей реализации архитектуры использовалось две блокировки, одна из них защищала поверхность, а другая - контекст устройства. Хотя они и защищали от одновременного вывода изображений на поверхность, но после изменения режима работа блокировок может быть нарушена. Блокировка поверхности была заменена на блокировку PDEVOBJ, препятствующую использованию объекта PDEVOBJ или связанной с ним поверхности при изменении режима. Тот факт, что это никогда не вызывало видимых проблем, скорее всего связан с тем, что никто и никогда не заходил так далеко, исследуя вопрос изменения режимов и не вызывал глобальных зависаний системы. Блокировка поверхности была удалена, осталась лишь блокировка PDEVOBJ для предотвращения попыток одновременного вывода изображений.

Другой обнаружившейся проблемой стали ошибки при обработке палитры. Палитра используется для облегчения преобразования битов, находящихся на поверхности, в значения цвета. Их реализация в ReactOS также оставляет желать лучшего, поскольку функции, необходимые для поддержки изменения режима, отсутствуют. Самая большая проблема случалась когда при изменении режима также изменялся бит, указывающий на глубину цвета, что могло сделать палитру, содержащуюся в PDEVOBJ, неправильной. К сожалению, предполагалось что у поверхности всё ещё та же самая палитра, что могло закончиться искажением цветов. Чтобы избежать возникновения этой ситуации, палитра была связана с поверхностью, которая будет изменяться при изменении режима и всегда иметь правильную информацию.

Помимо исправлений поддержки изменения режимов, разработчикам пришлось заняться также несколькими старыми проблемами. При очень специфических условиях, подсистема win32k оказывается в ситуации, когда несколько потоков попытаются установить исключительные блокировки на несколько объектов в разном порядке. Эти условия немедленно привели бы к взаимной блокировке, поскольку ни одна из них не может быть удалена пока обе из них установлены. К сожалению, какие бы ни были условия, блокировка никогда не должна зависеть от столь неопределенных вещей, поскольку сама система может рухнуть при сочетании всех этих условий. Код, исправляющий эту ошибку, обеспечивает особый порядок установки блокировок, в первую очередь позволяющий избежать таких ситуаций. Другие изменения, внесенные в ветвь, призваны повысить производительность. Точечные изображения ранее размещались в пуле подкачиваемой памяти, ресурсы которого, несмотря на его название, всегда дефицитны и не должны растрачиваться впустую. В ветви расположения точечных изображений были изменены на основную системную память. Вообще-то Windows размещает их в памяти сессии, но в ReactOS ещё недостаточно хорошо реализована поддержка сессий, чтобы это можно было сделать. Тем не менее, это позволяет устранить ещё одного претендента на пул памяти.

Повреждения памяти

Не так давно, Алексей Брагин реализовал проверку целостности пула для поиска ошибок, приводящих к повреждению данных в ReactOS. Эта проверка работает по принципу заполнения пула и проверки, не произошла ли запись на дополнительные страницы. К сожалению, этот механизм не работает должным образом из-за многочисленных изменений в менеджере памяти пула. У Михаэля Мартина (Michael Martin) на данный момент есть система для проверки пула неподкачиваемой памяти. Метод Михаэля состоит в использовании функции QEMU, с которой может соединиться GDB и просмотреть доступ к памяти. Михаэль создал свою собственную сборку QEMU, позволяющую зарегистрировать и проконтролировать каждый блок памяти в ReactOS, адрес которого указывает на выделение памяти из пула. Каждый раз, когда ReactOS использовал невыгружаемый пул, сборка QEMU Михаэля сверялась со списком сохраненных адресов для того, чтобы убедиться что операция была произведена с правильным блоком памяти. Разумеется, это чрезвычайно замедлило систему, и потребовалось приблизительно пять минут, чтобы загрузить графический интерфейс пользователя (GUI) ReactOS. Если происходил неправомерный доступ к памяти, сборка QEMU Михаэля "обрушивала" операционную систему и переключала пользователя в интерфейс отладчика, позволяя ему проверить код инициатора доступа.

В настоящее время Михаэль столкнулся с четырьмя ошибками, приводившими к повреждениям пула, три из которых находились в его собственном коде. Первая из них происходила из-за остатков кода после того, как он исправил цикл обработки внеочередных сообщений, об этом мы уже рассказывали в 72-ом выпуске новостей, где говорилось о системных сообщениях, которые не проходили через цикл обработки очередных сообщений. Другие две проблемы находились в новом коде USB-стека Михаэля, одна являлась простой опечаткой, а другая представляла собой ошибку вычисления смещения. Все три были устранены. Последней, но ещё не устранённой проблемой является повреждение пула, создаваемое драйвером UniATA. Над решением проблемы всё ещё ведётся работа, но, как мы надеемся, Михаэль использует свой новый инструментарий и скоро устранит её, хотя и очень медленно.

Ещё одним последствием повреждения памяти стали проблемы при попытке воспроизвести звук на реальном оборудовании. Тестеры пытались заставить драйвера работать, но каждый раз это заканчивалось неудачей, поскольку где-то в памяти ядра происходило повреждение памяти. Недавняя работа команды ARM над невыгружаемым пулом, как кажется, выявила повреждения, однако пока Йоханнесу Андервальду (Johannes Anderwald) не удалось найти их причину. К сожалению, Михаэль не может использовать свой инструментарий для тестирования этой ошибки, так как она не проявляется в QEMU. Однако, каждое повреждение, которое он обнаружит, может быть тем самым, с которым столкнулись тестеры.

Уведомления файловой системы

Хотя Пьер Швейцер (Pierre Schweitzer) и не проявлял особой активности в течение некоторого времени, однако он был занят изучением и реализации уведомлений файловой системы в ReactOS. Отсутствие уведомлений непосредственно ответственно за ряд проблем в ReactOS, особенно в оболочке. Одним из ярких примеров является ситуация, когда при деинсталляции программы оболочке необходимо знать, что каталог программы был удалён. При этом файловой системе необходимо проинформировать оболочку об удалении каталога, но без уведомления это не представляется возможным. Другие возможные проблемы были скрыты за ошибками и отсутствующей функциональностью в других частях системы. Существует два типа уведомлений, в одном из них для информирования системы об изменении состояния дискового тома, используется PnP (Plug'n'Play), это, например, монтирование и размонтирование USB-устройств. Второй тип уведомления относится к изменениям в каталогах.

С помощью этих двух типов, Пьеру удалось частично реализовать уведомления о внесении изменений в раздел. Его усилиям в значительной мере препятствовало "сырое" состояние подсистемы PnP в ReactOS. Все уведомления, отправляемые подсистемой для оповещения заинтересованных в этом программ и пользователей, проходят через диспетчер PnP. Когда программа сообщает операционной системе, что она хочет получать уведомления о изменении состояния раздела, диспетчер PnP регистрирует её и поддерживает список заинтересовавших её объектов.

Файловые уведомления по-прежнему требуют приложения значительных усилий, однако Пьер, по крайней мере, заложил фундамент для этого. Ранее, мы уже рассказывали о библиотеке файловых систем времени выполнения FsRtl (FileSystem Runtime Library), которая также является детищем Пьера. Одной из задач FsRtl является первоначальная обработка уведомлений как файлов, так и томов. Перенаправление уведомлений осуществляется в зависимости от их типа, а именно, диспетчер PnP занимается оповещениями о состоянии разделов, о чём мы рассказывали выше, а FsRtl поддерживает файловые уведомления. Когда программа запрашивает оповещения об изменениях, драйвер файловой системы отправляет пакет запроса ввода/вывода (IRP) с информацией о том, что программа хочет получать уведомления. Драйвер регистрирует это уведомление в списке всех заинтересованных в оповещении изменений файлов объектов, который ведет FsRtl. Если обнаруживается совпадение со списком, FsRtl добавляет необходимую информацию и отправляет IRP. У Пьера в патче уже имеется рабочая реализация регистрации уведомлений, а также он продолжает работу над отправкой уведомлений. По завершении этого, Пьер планирует заняться другими проблемами, имеющимися в поддержке файловых систем в ReactOS.