ROS Newsletter70

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

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

Тайминг UniATA

Продолжаются проблемы, связанные с UniATA. Тестеры, которым из-за этих проблем сложно завершить даже первую стадию установки, не могут в полной мере содействовать развитию ReactOS. Мы уже писали о том, что время ожидания ответа от аппаратуры в UniATA было значительно снижено по сравнению со старым драйвером ATA. Некоторые устаревшие приводы не могут обеспечить достаточной скорости отклика на команды и это приводит к тому, что заканчивается время, отведённое на операцию. Поэтому UniATA сообщает об ошибке, даже если технически всё было правильно. Первая попытка решения этой проблемы состояла в установке в UniATA времён ожидания, используемых старым драйвером, но несколько разработчиков были несогласны с таким подходом. Тогда Олаф Сиежка (Olaf Siejka) стал искать "компромиссное" время задержки (то есть такое, которого было бы достаточно для ожидания ответа от большинства аппаратных средств), и идентифицировать, на чем конкретно заканчивается время ожидания. Это было непростой задачей, и терпение Олафа весьма похвально.

Одна из главных проблем, связанных с UniATA - пропуск загрузочного диска. Это мог быть и привод компакт-дисков, и жесткий диск, но так или иначе эта проблема эффективно мешала ReactOS, поскольку терялся привод с операционной системой. Хотя Олаф был не единственным, столкнувшимся с этим, поскольку и Даниэль Реймер (Daniel Reimer) и Габриэль (Gabriel) при других обстоятельствах сталкивались с той же самой проблемой. Даниэль готовился к выставке Chemnitz expo и хотел использовать свой ноутбук для демонстрации ReactOS, но не смог заставить UniATA функционировать на нём. Габриэль тестировал ReactOS на VirtualBox, но его CD-привод был установлен ведомым устройством на первичном канале. Алексею Брагину удалось установить причину проблемы, возникшей у Габриэля, но Олаф и Даниэль всё еще испытывали трудности. Что интересно, когда Олаф переключил UniATA в режим полной отладки, проблема исчезла, что наводит на мысли о проблеме с таймингом. После этого была проведена гиганская работа, заключающаяся в ручной установке и удалении операторов вывода отладочных данных в каждой функции UniATA, позволившая Олафу выделить три проблемные функции, отвечающие за обработку прерываний. Тем не менее, оказалось что это не истинная причина проблемы, так как если отладчик останавливается на этих трёх функциях, то проблема не появляется. Таким образом проблема может быть гораздо более глобальной, нежели чем эти три функции, и только дальнейшее и более тщательное тестирование поможет её выявить, после чего можно будет сделать какие-либо выводы. Тем временем, команда ARM и Тимо Кройцер (Timo Kreuzer) были заняты переписыванием кода обработчика прерываний, что может привести к другим изменениям в тайминге обработчика прерываний. Так что настоящая причина проблемы возможно кроется где-то ниже в стеке.

PnP и ACPI

Plug and Play - это технология, предназначенная для того, чтобы операционная система могла определить новое и/или присоединённое оборудование. К примеру, если установить в компьютер новую графическую карту, ОС узнает об изменении через механизм PnP. В противном случае процесс определения нового оборудования необходимо было бы начинать пользователю, а это не очень-то приятная задача. PnP в ReactOS не был закончен по многим причинам и различные его части были заменены хаками, чтобы компенсировать отсутствующие компоненты. Одним из недостатков был Freeloader, загрузчик ReactOS, сообщающий менеджеру PnP о различных устройствах, которые он обнаружил. В результате операционная система не знала, инициализировать ли ей драйверы, которые у неё имеются для этих устройств, или запросить установку этих драйверов, если у неё их нет. Недавно Кэмерон Гутман (Cameron Gutman) добавил необходимый код и, кроме того, закончил доработку нескольких других исправлений, связанных с описанием устройств, обработкой которых также занимается менеджер PnP.

В процессе этой работы Кэмерон наткнулся на баг, из-за которого компьютер не мог определить поддержку ACPI. Усовершенствованный интерфейс конфигурации и управления электропитанием (Advanced Configuration and Power Interface, ACPI) используется для управления питанием и аппаратными устройствами на системах, которые его поддерживают. Поддержка ACPI в ReactOS колеблется в диапазоне от несущественной до полностью отсутствующей, в зависимости от того, на какой уровень операционной системы смотреть. Одной из проблем был диспетчер PnP, который поддерживал не все устройства, о которых ему сообщал загрузчик операционной системы. Начальный загрузчик ReactOS, Freeloader, сохраняет список обнаруженных им устройств в реестр, а диспетчер PnP должен его считывать и создавать дополнительные записи в реестре для всех устройств. Взаимодействие между ними требует наличия данных с правильными идентификаторами PnP, которые должны быть жестко прописаны в коде. К сожалению, PnP менеджеру не хватало нескольких идентификаторов, поэтому некоторые устройства не получали запись в реестре. Результатом становилось то, что операционная система не знала, инициализировать ли ей драйверы, которые у неё имеются для этих устройств, или запросить установку этих драйверов, если у неё их не имеется. Недавно Кэмерон Гутман (Cameron Gutman) добавил необходимые идентификаторы, а также закончил доработку нескольких других исправлений, связанных с описаниями устройств, обработкой которых также занимается менеджер PnP. Ещё одной проблемой было то, что ключ реестра драйвера ACPI был помечен флагом как изменяемый, что приводило к переустановке драйвера ACPI после каждой перезагрузки. Кэмерон устранил эту ошибку, но его новые разработки, по всей видимости, упираются в очень старый хлам в более низких уровнях операционной системы. Сейчас многие пользователи испытывают проблемы с мышью на втором этапе установки, а также на рабочем столе после первой загрузки ОС, и в настоящее время команда ARM рекомендует оставить ACPI отключенным до тех пор, пока в Уровне абстракции от оборудования (Hardware Abstraction Layer, HAL) не будет более полной поддержки ACPI.

DVB-T

Стандарт DVB-T (Digital Video Broadcasting-Terrestrial) - один из вещательных стандартов цифрового телевидения. Он используется в Европе, России, Гренландии, части Африки, юге Азии, и ещё некоторых других частях мира. Компьютеры с цифровыми тюнерами могут принимать телевизионный сигнал, а операционная система, разумеется, должна поддерживать декодирование этого сигнала. Йоханнес Андервальд (Johannes Anderwald) решил прервать работу над поддержкой звука до тех пор, пока не поступит достаточное количество детальных отчётов об ошибках, а в ожидании этих отчётов заняться разработкой поддержки DVB-T в ReactOS. Для этой задачи потребуется программный стек, простирающийся из режима пользователя в ядро. Также необходимы компоненты ядра, такие как ks.sys - широко известный как компонент ядра для обработки потоков, который требовался также для поддержки звука, и bdasup.sys - драйвер для поддержки различных вещательных устройств, например, ТВ-тюнеров. Набор компонентов, находящийся в пользовательском режиме, состоит из нескольких фильтров DirectShow и компонентов захвата, таких как msdvbnp и ksproxy, а также bdaplgin, который представляет собой ksproxy, используемый для взаимодействия с компонентами ядра. Эти фильтры определяют канал, на который должно настроиться ядро, а затем получают и перенаправляют аудио/видео поток от ядра в пользовательский режим. Разумеется, пользователю всё ещё необходимо приложение для декодирования и воспроизведения этого потока, однако подобрать нужное не составит труда. Йоханнес проверял свой код пользовательского режима по большей части на Windows XP, заменяя регистрации COM таким образом, чтобы работал его стек, а не стек, включенный в состав Windows. При переходе к тестированию компонентов ядра, Йоханнес, по всей вероятности, будет использовать оригинальные фильтры DirectShow, чтобы уменьшить вероятность возникновения сбоев. Хотя полная поддержка по-прежнему отсутствует, Йоханнес добился довольно многого за короткий промежуток времени. Те, кто захочет, чтобы он с такой же скоростью работал над звуковой подсистемой, должны будут мотивировать его, предоставляя более подробные отчёты об ошибках и отладке.