Привет! В этой серии мы продолжаем усиленно дружить драйвер WinBtrfs с ReactOS.
А этот ваш Windows так умеет?
Начнем по порядку. После предыдущего поста, был реализован мини-драйвер для загрузчика FreeLoader, позволяющий в read-only режиме читать файлы с раздела BTRFS. Здесь меня поджидала первая проблема — BTRFS это регистрозависимая файловая система. Здесь для поиска inode структуры (эта структура содержит базовую информацию о файле) в директории используется хеш имени файла, это позволяет ходить по путям без вытаскивания всех файлов, содержащихся в директории.
Однако, в Windows мире такая вещь как регистр имени файла мало кого волнует, поэтому пути к драйверам, требующимся для загрузки ОС могут быть записаны в реестре в совершенно любом регистре.
В данный момент эта проблема решена старыми добрыми костылями — при запросе на поиск файла, System32 и SYSTEM32 заменяются на system32, то же самое с папкой drivers. Пока я думаю как можно было бы это сделать грамотно. Скорее всего буду каждый раз загружать полный список файлов в директории и делать регистронезависимый поиск — потери скорости на загрузчике особо видны не будут.
Загрузчик читает файлы, костыли закостылены — едем дальше.
Я разрабатывал код загрузчика в виртуальной машине Bochs, поскольку в ней такие вещи делать удобнее всего. Но она (как оказалось) имеет проблемы с запуском ReactOS, поэтому пришлось пересесть на привычный VirtualBox.
И тут меня ждала очередная засада — почему-то не работал загрузочный сектор. Как выяснилось, в реализации прерывания INT 13h AH=42h (расширенное чтение с диска) есть какие-то проблемы, из-за которых эта функция не может читать более 8 секторов за раз.
И вот, наконец, первое сообщение об ошибке (это даже не BSOD!)
Исключение со STATUS_ACCESS_VIOLATION приходило из подсистемы WinSxS, которая в основном взята из Wine. Пару дней пришлось потратить на причину возникновения, поскольку через WinSxS проходит загрузка всех библиотек, а их при запуске много. В конце концов, выяснилось что проблема была не в WinSxS (фух), а в системном вызове NtQueryDirectoryFile.
WinSxS часто использует эту функцию для поиска манифестов по маске (делая запросы типа таких: "*_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.*.*_*_*.manifest"), а в драйвере WinBtrfs закрался баг, связанный с обработкой масок, начинающихся на звездочку. Совсем простенький пулл-реквест можно посмотреть здесь.
Удивительно, но этого было достаточно для того, чтобы пройти установку и загрузиться в рабочий стол
Возможно, первая в мире загрузка с драйвера WinBtrfs. Первая реализация моего фикса тоже имела ошибки, из-за чего кое-где поехала графика и не загружались картинки.
Собственно, система загружается, и даже работает (хотя стабильность не такая как в последнем релизе 0.4.9).
Но проблем ещё полно:
- Нет поддержки файла подкачки. Вообще говоря, на linux swap файлы на btrfs дисках тоже не поддерживаются, а патч висит уже несколько лет. Но WinBtrfs таки их поддерживает. У нас же несколько другая реализация менеджера памяти, чем в Windows, которая требует ещё одного системного вызова, отсутствующего пока в WinBtrfs.
- Ошибки записи и переполнения памяти. Мне удалось зафиксировать парочку таких, например при установке клиента Git. Будем разбираться, где течет память
- BSODы при выключении и перезагрузке. Патч уже ждет одобрения
До конца GSoC осталось уже совсем чуть-чуть, в планах дальнейшее исправление багов, и решение проблемы с файлом подкачки (но это уже после окончания программы).
Ну а желающие поддержать разработку данной фичи, могут присоединиться к тестированию и разработке драйвера WinBtrfs.
Автор: Extravert34
