ROS Newsletter68

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

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

ARWINSS: Бог троицу любит?

Несмотря на несколько заявлений Алексея Брагина о том, что такое ARWINSS, все еще остались те, кто ничего не понял и, к тому же, вводит в заблуждение других. Неразбериха зашла так далеко, потомучто люди, обладающие неполной информацией, стали подавать свои ошибочные предположения как факты. ARWINSS не предназначена для "замены" текущей подсистемы Win32. Она является попыткой преодолеть ограничения в текущей подсистеме Win32, используя несколько другой подход, чем просто воспроизведение архитектуры Win32 из Windows NT. Кроме того, ARWINSS связана только с подсистемой Win32, и, следовательно, является лишь частью проекта ReactOS и не представляет операционную систему в целом. Поэтому высказывания вроде "ReactOS начинает всё сначала" являются по меньшей мере сильно преувеличенными. В процессе работы над ARWINSS будут выявлены все её технические достоинства и недостатки, в то время как работы над текущей реализацией Win32 будут продолжены, но нет ничего, что могло бы помешать сосуществованию этих двух реализаций подсистемы Win32. Это - наиболее общий стратегический обзор ARWINSS и мы надеемся, что после его прочтения станет ясно, что глобальных изменений в проекте и дизайне ROS не произойдёт.

Что касается самой ARWINSS, её реализация основана на архитектуре, используемой в настоящее время в Wine. В Wine есть несколько уровней, и большинство повторно используемого кода работает поверх драйвера, который абстрагирует детали взаимодействия с нижележащей графической подсистемой. Для каждой графической системы, в которой предполагается использование Wine, требуется отдельный драйвер. В данный момент существует драйвер X11 (для X-сервера), который называется winex11, и идёт работа над драйвером для Quartz (графической подсистемы MacOS X). Но не существует драйвера для графической системы Win32 - скорее всего из-за того, что ранее в нём не было необходимости. Однако, ARWINSS включает реализацию такого драйвера (под названием winent), представляющего собой уровень между различными DLL, реализующими подсистему Win32 Wine и компонентами ядра подсистемы Win32 - Win32k. Библиотеки DLL подсистемы Win32 могли бы и напрямую обратиться к Win32k при помощи системных вызовов, но реализация Wine, как сказано выше, требует наличия посредника. Более того, драйвер пользовательского режима обрабатывает лишь взаимодействие с графической системой, а некоторые другие службы или ресурсы, необходимые библиотекам DLL в Wine, обеспечиваются компонентом, который называется wineserver. К счастью, так как большая часть функциональных возможностей, обеспечиваемых wineserver, уже была так или иначе реализована в ReactOS, Алексей сделал переадресацию вызовов DLL к библиотекам и функциям ReactOS. Присутствие winex11 в некоторых диаграммах и даже в репозитории повлекло за собой предположения, что ReactOS так или иначе планирует использовать X Windows. Однако, как было сказано выше, winex11 уже существовал как часть проекта Wine и был просто перенесен в процессе первоначального импорта. Его использование не является обязательным для ReactOS. Фактически, он был заменен драйвером winent, написанным Алексеем. Таким образом, ни у одного из разработчиков, работающих над ARWINSS, не было никаких намерений относительно использования X Windows, и повышенное внимание к X11 стало для них неожиданностью, так как не имело ни малейшего отношения к их работе.

Также, необходимо сделать пояснение относительно различий между ARWINSS и Wine на Unix. Поскольку система X Windows работает в пространстве пользователя, взаимодействие с ней требует чего-то подобного RPC (удалённым вызовам процедур), и в течение долгого времени X Windows не могли сделать обработку этих вызовов проще или быстрее. В сравнении с системным вызовом между пользовательским режимом и режимом ядра, такие вызовы являются более дорогостоющими. Как следствие - падение производительности Wine, работающего в Unix. В ReactOS же драйвер winent просто выполняет системные вызовы Win32k (части Win32, работающей в режиме ядра).

Прогресс в разработке Менеджера памяти

В течении последних нескольких месяцев Арт Йеркс (Art Yerkes) добился больших успехов в разработке менеджера памяти, переписав и упростив различные его компоненты. Одним из этих компонентов является балансировщик (balancer) - компонент, определяющий, какие страницы памяти должны быть сброшены на диск. Другой компонент - диспетчер модифицированных страниц (mpw - modified page writer) - заработал после того как Арт упростил механизм блокировки ресурсов, производимой во время операций со страницами памяти. Когда mpw требуется сбросить страницы из физической памяти, чтобы освободить место для новых данных, он попытается сбросить те, что еще не были изменены, так как при этом не потребуется производить реальной записи страницы на диск. Чтобы сократить число измененных страниц требуется периодически сбрасывать их на диск во время простоя системы, что и делает mpw. Однако, этот механизм не работал в ReactOS из-за теоретически возможного, но крайне сложного метода решения проблем синхронизации во время проведения операций с памятью.

Поначалу код менеджера памяти в ReactOS был относительно прост, и в течение долгого времени его количество увеличивалось лишь для обеспечения синхронизации при работе с данными и предотвращении взаимных блокировок. Одной из попыток управления ресурсами стал pageops, который включает в себя данные о состоянии обработчика ошибок при обработке им определенного адреса определенного процесса. Арт не уверен, что кто - либо еще использует pageops, праобраз которого был создан Дэвидом Велчем (David Welch), прежним главным разработчиком ядра ReactOS. Однако, реализация pageops в ReactOS привела к большому количеству повторяющегося кода в обработчиках ошибок страницы из-за необходимости следить за тем, как работают или к чему имеют доступ остальные обработчики ошибок. Арт удалил pageops из своей сборки и использовал контрольные значения для того, чтобы можно было быть уверенным, что другие процессы находятся вне контролируемой области, пока они не активизированы. Хотя это крайне упрощенный способ работы с разделяемыми объектами, он также является и наиболее простым способом получить работающий компонент. Для ReactOS, на данный момент, корректное функционирование имеет гораздо более высокий приоритет, чем теоретическая оптимизация.

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

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

Результатом всех проведённых работ стала более стабильная работа с виртуальной памятью в ReactOS, по крайней мере на сборке Арта. Виртуальная память важна тогда, когда ОС или приложения используют больше памяти чем физически имеется. Именно из-за этого ReactOs не могла ранее обеспечить хорошую производительность и целостность данных в подобных ситуациях. Теперь же Арт смог безопасно запустить ROS на системах со всего 32 МБ памяти. Дальнейшее уменьшение количества оперативной памяти вряд ли возможно, принимая во внимание размер кода и данных, которые должны оставаться в памяти для обработки страниц, да и вряд ли в этом есть необходимость, так как система, обладающая таким небольшим количеством памяти, едва ли сможет делать что-либо ещё, помимо выполнения ReactOS.

Поддержка ext2

Приводя контроллер кэша в надлежащий вид, Арту удалось также обеспечить загрузку и работу ReactOS на разделе ext2. Программа установки сама по себе не поддерживает ext2, поэтому Арт просто перенёс ReactOS на раздел, а затем использовал GRUB для загрузки freeldr. Кроме того, Пьером Швейцером (Pierre Schweitzer) проведена работа над над runtime-библиотеками файловой системы, поэтому Арту необходимо было всего лишь сделать несколько дополнений в них. Простейшим решением стало введение заглушек для соответствующих функций механизмов блокировок в файловой системе - функциональность, прежде всего используемая сетевыми файловыми системами. На самом деле локальная файловая система в этом не нуждается, но Мэтт Ву (Matt Wu), разработчик драйвера ext2, которым сейчас пользуется Арт, довольно тщательно следовал правилам написания драйверов файловой системы, и предложил полностью придерживаться спецификаций. Это, кстати, делает драйвера Мэтта прекрасным выбором для тестирования. Необходимо было внести еще два других, более сложных дополнения - это блоки управления памятью и блокировка диапазона. Оба этих дополнения связаны с отображением блоков файловой системы на блоки диска. Всё ещё требуется несколько изменений инфраструктуры, чтобы можно было в полной мере воспользоваться результатами работы Арта и Пьера. Как упоминалось выше, программа установки фактически не поддерживает использование разделов ext2 и ещё требуется уделить внимание загрузчику. Тем не менее, эти изменения служат ступеньками к использованию более современных файловых систем в будущем; в настоящее время разрабатывается новый драйвер FAT и скорее всего, по завершении работ над обоими драйверами мы ощутим пользу от использования этих двух файловых систем. Наконец, следует отметить, что значительная часть работы находится не в основной, а в отдельных ветках, так что, возможно, пройдёт ещё немало времени, прежде чем такая функциональность появится в релизах.