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

Z98, “ReactOS Newsletter: Newsletter 89”, public translation into Russian from English More about this translation.

Translate into another language.

RPC

Вызов удалённых процедур (Remote Procedure Call, сокращённо RPC) используется множеством разных компонентов Windows, в особенности службами. Таким образом динамическая библиотека вызова удалённых процедур (rpcrt4) имеет довольно важное значение для обеспечения непрерывной и стабильной работы системы. Кроме того, реализация этого компонента в ReactOS основана на коде проекта Wine. К сожалению то, что код Wine работает в Linux, вовсе не означает, что он будет работать в ReactOS, и все предыдущие попытки синхронизировать rpcrt4 приводили к множеству проблем и сбоев в ReactOS. Томас Фабер (Thomas Faber), студент, участвовавший в Google Summer of Code с проектом по реализации новой системы для тестирования компонентов ядра, обнаружил, как он полагает, основную причину возникновения критических сбоев RPC в ReactOS. Когда процесс совершает вызов удалённой процедуры, он получает дескриптор этого вызова. Этот дескриптор представляет собой уникальный идентификатор каждой операции RPC, а его уникальность должна был быть гарантирована генератором случайных чисел. Wine для этих целей использует генератор случайных чисел Linux, расположенный в /dev/urandom, которого в ReactOS, разумеется, нет. В дополнение ко всему прочему, оказалось что в коде ReactOS отсутствует функция NT, которую Wine использует для генерации случайных чисел, поэтому при запросе на получение уникальных идентификаторов для разных операций RPC могли выдаваться одинаковые значения. Это приводило операционную систему в замешательство и ломало функциональность всего, что зависело от RPC. Томас занимается этой проблемой, и, мы надеемся, что в будущем попытки синхронизировать rpcrt4 с кодом Wine не будут приводить к катастрофическим последствиям для операционной системы.

Диспетчер памяти

Многие тестеры высказывали своё недовольство по поводу зависания процесса установки ReactOS во время попытки копирования файла mshtml.dll. Попытки диагностировать проблему привели разработчиков глубоко в недра диспетчера памяти и выявили довольно большое количество ошибок в коде этого модуля. Причина зависания заключалась в обнулении структур данных, что приводило к тому, что диспетчер кучи терял способность отслеживать блоки памяти во время копирования файла mshtml.dll. Без этой информации диспетчер кучи не мог получить следующий блок памяти и зависал в бесконечном цикле. Уже третья (а может и того больше) команда разработчиков попробовала свои силы в устранении этой проблемы, и все они приходили к одинаковому выводу: переписывание диспетчера памяти, начатое в ARM3, должно быть завершено как можно скорее. Томас был одним из участников команды по устранению этой проблемы, и вначале решил, что ошибка вызвана компонентом setupapi, который производит установку драйверов, библиотек, и связанных файлов. Это было обусловлено довольно захламлённым состоянием и сложностью кода setupapi, поэтому Томас предположил, что ошибка возникает из-за переполнения памяти и тому подобных проблем. Для проверки этой теории Томас создал свой собственный диспетчер кучи и запустил setupapi поверх него. В результате setupapi был реабилитирован, поскольку начали появляться сбои, не связанные с setupapi. Это означало, что проблема находится куда гораздо глубже в диспетчере памяти. Ещё большим разочарованием стало то, что сбои, похоже, зависели от тайминга, что само по себе предполагало вероятный конфликт ресурсов.

В Крестовом походе на MSHTML принимал участие и Кэмерон Гутман (Cameron Gutman), однако ему пришлось отвлечься на патч, предоставленный Николаем Мыльцевым и связанный с работой подкачки. Вообще, объём виртуальной памяти, затребованный приложением, и объём этой памяти, в действительности находящейся в физической памяти, это две разные вещи. В Windows, рабочий набор представляет собой страницы виртуальной памяти процесса, с которыми недавно происходила работа, и для всех процессов имеются максимальный и минимальный размеры рабочего набора. Windows попытается сохранить рабочий набор страниц в физической памяти, предполагая, что для этого имеется достаточно свободного места. Предназначением рабочего набора является предотвращение поглощения всей физической памяти одним приложением, и диспетчер памяти балансирует потребление памяти каждого из процессов путем изъятия страниц из рабочих наборов разных процессов, если в этом возникает необходимость. Страницы, содержимое которых было изменено в оперативной памяти, должны быть записаны обратно на диск до того, как занимаемый ими блок памяти может быть использован повторно. Когда приходит время для изъятия страниц из рабочего набора, операционная система будет искать достаточное количество чистых, немодифицированных страниц, которые она могла бы повторно использовать, получая тем самым необходимое количество свободной памяти. Система должна также постараться записать изменения в занятых страницах, если в её распоряжении имеется недостаточное для удовлетворения запроса на выделение памяти количество свободных страниц, однако как раз этого в ReactOS и не происходило. Эта ошибка в конечном итоге приводила к тому, что у балансировщика рабочего набора заканчивались страницы, которые он мог бы изъять из рабочего набора, в результате чего происходил критический сбой операционной системы. Просмотрев созданный Николаем патч и сделав в нём несколько своих изменений, Кэмерон добавил результаты своей работы в кодовую базу проекта, и теперь балансировщик корректно записывает изменения в занятых страницах, что позволяет использовать их повторно.

Микрокоды процессора

Эта тема требует небольшого погружения в проектирование и изготовление ЦП. Большинство программистов понимает, что каждое из семейств процессоров подчинено своей архитектуре набора команд (Instruction Set Architecture, сокращённо ISA), определяющей, какие инструкции и операции процессор может выполнить. Однако многие люди не знают или не задумываются, что большинство процессоров на самом деле не выполняют инструкции, определённые ISA, напрямую. В действительности существует более низкий уровень команд, это так называемые микрокоды, которые управляют работой процессора таким образом, чтобы результат соответствовал требованиям ISA. Эти микрокоды по большей части абсолютно недокументированы, поскольку и у AMD и у Intel они представляют собой коммерческую тайну. Архитектура современных ЦП чрезвычайно сложна, и в ней могут существовать аппаратные ошибки, приводящие к неправильной обработке микрокода. Устранение такой проблемы в аппаратных средствах потребовало бы изменения архитектуры, но в современных ЦП возможно скомпенсировать эти ошибки, обновив микрокод. AMD и Intel предоставляют модификации микрокода разработчикам операционных системы в виде двоичных файлов, однако компонент Windows, в котором используются эти патчи, не документирован. Пьер Швейцер (Pierre Schweitzer) занялся этим вопросом и у него возникли некоторые мысли относительно того, как ReactOS может обновлять микрокод, но на данный момент проблема имеет довольно низкий приоритет и требует дальнейшего изучения. В любом случае, это довольно интересная проблема, выделяющаяся рядом сложностей, с которыми можно встретиться на самых низких уровнях аппаратных/программных интерфейсов.

Установка системы

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

Scatter/Gather DMA

В традиционных операциях прямого доступа к памяти (DMA) необходим единый непрерывный блок памяти требуемого размера, в который будут передаваться данные. К сожалению, не всегда в распоряжении системы имеется блок памяти необходимого размера. Прямой доступ к памяти по механизму "Scatter/Gather" призван исправить эту проблему путём использования кусков меньшего размера, сохраняя данные об их размещении и записывая данные в них. Основная часть кода поддержки S/G DMA уже имелась в ReactOS, однако API, который предоставлял бы её функциональность, отсутствовал. Кэмерон взялся и разработал этот API, что позволило работать в ReactOS драйверам, использующим механизм S/G DMA, по большей части это драйверы сетевых карт.

Оптимизация использования памяти во FreeLoader

Недавно Тимо Кройцер (Timo Kreuzer) заметил, что freeldr довольно неэффективно использует память. Фактически существует два типа данных, для которых freeldr требуется память: данные, которые передаются им ядру, и данные, которые необходимы лишь самому freeldr для завершения загрузки операционной системы. Первоначально freeldr выделял единый блок размером 4 Мб и использовал его для обоих типов данных, при этом ядру приходилось читать все 4 Мб данных. Посчитав это несколько расточительным, Тимо разбил единый кусок на две разные кучи, по одной для каждого типа данных. Это позволяет freeldr освобождать всю память, не имеющую отношения к ядру, что приводит к существенному уменьшению количества занятой памяти. Вроде бы небольшое изменение, однако такие небольшие изменения, как это, могут многое изменить в долгосрочной перспективе.

Исправления путей

Множество регрессий, вызванных новым загрузчиком, были связаны с не совсем верным поведением некоторых функций, имеющих дело с путями. Поскольку загрузчик во время своей работы совершает множество операций доступа к файлам, необходимым для загрузки исполняемых файлов и библиотек, он активно использует функции обработки путей. Алекс Ионеску (Alex Ionescu) недавно уделил время переписыванию большой части основных функций, связанных с конвертацией и перекодированием строк, обработкой ярлыков и исправлением кодов ошибок при критических сбоях. Всё это вместе взятое вылилось в устранении значительного количества регрессий, связанных с загрузчиком, и, надеемся, позволит ещё большему количеству приложений функционировать корректно.

© ReactOS Team

Original (English): ReactOS Newsletter: Newsletter 89

Translation: © evilslon, Сергей, tipys .

translatedby.com crowd

Like this translation? Share it or bookmark!