ROS Newsletter71

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

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

USB-стэк в NT

До Windows Vista архитектура USB основывалась на драйвере самого низкого уровня - usbport. Именно он создавал объекты устройств для каждого контроллера USB и получал пакеты запроса ввода-вывода (IRP). В зависимости от того, какой стандарт поддерживали контроллеры, usbport вызывал один из трёх вспомогательных драйверов - usbehci, usbohci, и usbuhci. В действительности все эти IRP отправлял usbhub, а перечисленные компоненты представляют собой низшие уровни USB-стека. Большинство драйверов USB поставляемых компаниями для своих периферийных устройств опираются на эти компоненты и пользуются преимуществами вспомогательной библиотеки под названием usbd. Без низших уровней стека нормальные клиентские USB-драйвера работать не будут, и именно это имели ввиду разработчики, называя нынешние драйвера USB "кривоватыми".

Михаэль Мартин (Michael Martin) работал над реализацией этих низкоуровневых компонентов. В настоящее время он написал базовый драйвер usbehci и тестирует его, пытаясь заменить usbehci драйвер Windows XP. Михаэль повторно использует части кода из pvdrivers, являющиеся частью Xen, однако количество кода, который можно оттуда взять для этих низкоуровневых компонентов, крайне ограничено. Мало кому когда-либо требовалось реализовывать нечто подобное, поэтому большую часть нужно написать с нуля. Пока что Михаэль добился определенных успехов в обеспечении взаимодействия менеджера PnP XP со своим драйвером, однако драйвер usbehci представляет собой лишь часть стека и нужно больше времени для того, чтобы получить что-то близкое к полному стеку.

Инструментарий сборки

При сборке объектов, компилятор GCC добавляет нижнее подчёркивание в начало имён функций, а компоновщик предполагает его наличие. Однако, это не позволяет использовать компоновку с объектами, созданными компилятором C/C++ от Microsoft, который Тимо Кройцер (Timo Kreuzer) хотел использовать для своей ветки x64. Существует флаг конфигурации -fno-leading-underscore, запрещающий GCC это делать, но он также должен передаваться компоновщику, и все используемые библиотеки также должны быть собраны с этим флагом. ReactOS использует несколько готовых библиотек C++ в движке сборки, а они изначально не были собраны с этим флагом. Для того, чтобы полностью решить проблему, так как binutils и GCC сами по себе не могли функционировать правильно даже в том случае, если им передавался этот флаг, потребовалось несколько дополнительных патчей для этих инструментов. Кай Тиец (Kai Tietz) из проекта MinGW-w64 помог в создании исправлений, которые позволили Тимо Кройцеру удалить хаки, которые он начал добавлять, чтобы компенсировать проблему.

Помимо работы над реорганизацией заголовков, Амин Хальди (Amine Khaldi) усердно работал над Clang и LLVM для сборки ReactOS. В Clang имеется множество ошибок, не позволяющих в настоящий момент его использовать, и вот этот отчёт описывает те, которые Амин нашёл на данный момент. Две из них к настоящему времени уже исправлены и Амин находился в постоянном контакте с разработчиками Clang по поводу других проблем. В любом случае, наличие большего числа возможностей для компиляции ReactOS - это всегда хорошо. Также, в списках рассылки Clang/LLVM велось обсуждение по вопросу добавления поддержки структурной обработки исключений (structured exception handling, SEH), которая будут очень полезна для ReactOS в долгосрочной перспективе, так как компилятор Microsoft является одним из немногих, которые действительно поддерживают SEH. Без какой-либо поддержки SEH, использование Clang и LLVM для сборки ReactOS будет невозможно. Другим вариантом может стать портирование библиотеки Portable SEH, написанной KJK::Hyperion, однако в процессе порта многое придётся в той или иной степени переписывать, поскольку в Clang и LLVM используемый для реализации SEH механизм будет другим.