Обновление загрузчика

После долгого перерыва, не дождавшись каких-либо комментариев, я наконец-то закоммитил большую часть изменений в коде загрузчика в head/ ветку.

Немного об изменениях. Было добавлено два программных интерфейса, назовём их PART и DISK. Первый предоставляет функции для работы с различными таблицами разделов: поиск метаданных таблиц разделов, парсинг и формирование списков разделов, получение информации по каждому разделу и т.п. На данный момент поддерживаются GPT, MBR, EBR, BSD label и VTOC8. Набор поддерживаемых таблиц разделов определяется переменными make на этапе компиляции. Обычно это GPT, MBR+EBR и BSD label.

PART API можно использовать напрямую, как это теперь делает ZFS, либо через DISK API. DISK API предназначен для использования в дисковых драйверах загрузчика. Интерфейс вобрал в себя всё общее, что есть между драйверами дисков загрузчиков разных аппаратных архитектур. Это позволило, во-первых, значительно упростить код драйверов, а, во-вторых, унифицировать алгоритмы их работы относительно определения таблиц разделов. Причём, эти алгоритмы почти на 100% совпадают с используемыми ядром. Поэтому, теперь не должно возникать ситуаций, когда загрузчик видит одни разделы, а ядро другие. Раньше такое было вполне возможно.

Основные особенности, которые попали в CURRENT:

• теперь loader умеет считать контрольную сумму для GPT заголовка и таблицы, а так же использовать резервную копию GPT;
• PMBR так же научился работать с резервной GPT;
• в качестве дополнительного бонуса, улучшенная поддержка EBR позволяет загрузить систему с логического тома. Правда boot0 делать этого не умеет, на сколько я помню.
• Так как ZFS научилась читать таблицы разделов, теперь она не перебирает все возможные комбинации разделов, а тестирует только те, на которых ZFS может быть установлена. Т.е. это разделы с типом "freebsd" и "freebsd-zfs", так что, если у вас есть загрузочный пул на разделах с другим типом, это нужно исправлять.

От идеи с определением метаданных GEOM в загрузчике пока отказались. Так же остались ещё патчи для uboot и архитектур arm/powerpc, которые так никто и не протестировал.

Мой студент в GSoC прошёл первый "отборочный тур", пока с небольшим отставанием от графика, но надежда на то, что скоро у нас на x86 заработает загрузка через EFI есть.

Дальше я планирую провести серию тестов по загрузке системы в различных конфигурациях с разным размером дискового кеша. Сейчас по-умолчанию его размер всего 16 Кбайт, и как показали первые тесты, его увеличение даёт прирост в скорости загрузки на несколько секунд, по крайней мере на моей машине.

В свободное время почитал код различных библиотек, утилит, загрузчиков и UEFI шелла, а так же документацию, какую удалось найти. Теперь уже гораздо лучше представлю, как будет работать наш UEFI загрузчик. Так что, если студент не справится, его работа не пропадёт даром :)

Ликбез по UEFI

Многие пользователи ПК имеют представление о том, что такое BIOS, для чего и как он работает. Но в последнее время появилась альтернатива, стремительно вытесняющая BIOS с наших ПК, а на серверном оборудовании уже прочно обосновавшаяся - это EFI и его более современный родственник UEFI.

Extensible Firmware Interface (EFI) впервые был предложен компанией Intel в качестве замены BIOS для своей новой 64-битной платформы IA64 (Itanium). Позднее Intel выпустила обновлённую спецификацию EFI 1.10, которая уже не привязывалась к платформе Itanium и могла использоваться для x86.

Чтобы труды Intel не пропали зря и народ обратил внимание на EFI был организован Unified EFI Forum, куда вошло несколько крупных компаний и который занялся дальнейшим развитием спецификации EFI. Чем он уже десять лет успешно занимается и на данный момент актуальной версией спецификации является UEFI 2.3.1.

Что же описывает эта спецификация? Честно говоря - МНОГО всего. Более 2000 страниц, и это только один из нескольких документов. UEFI firmware уже можно сравнивать с операционными системами. Для UEFI есть свои драйверы, свои сервисы и приложения. Даже есть свой шелл, который описан в отдельном документе UEFI Shell Specification. А вообще, конечно, идея правильная. Хорошо, когда всё стандартизовано и есть конкуренция, чего нельзя было сказать о BIOS.

Кстати, таблица GPT тоже описана в спецификации UEFI.

Итак, как же всё это работает? Разработчик аппаратной платформы пишет firmware, которая соответствует спецификациям UEFI и выполняет действия по описанным протоколам. Существует несколько инструментариев для разработчика связанных с UEFI компонентов. Некоторые из них - закрытые и коммерческие, некоторые - с открытым исходным кодом и свободно распространяемые. Разрабатывать firmware на ассемблере теперь нет нужды, хотя это тоже возможно. К интрументариям разработчика прилагаются все необходимые библиотеки и заголовочные файлы для разработки на языке Си. То же относится и к драйверам, и к EFI приложениям.

Так вот, эта firmware подобно BIOS помещается во flash память и в общем-то, цель у неё такая же - инициализировать оборудование для работы и передать управление операционной системе. Архитектурно она организована модульно и состоит из нескольких уровней, выполняющихся на различных этапах загрузки с момента включения питания. Подробную схему того, какие модули выполняются в какой момент времени, можно посмотреть в UEFI Platform Initialization Specification. Если в кратце, то это: предварительная инициализация памяти, процессоров, устройств и подготовка окружения для запуска следующих уровней firmware; загрузка драйверов устройств и запуск менеджера загрузки, который выполняет выбор устройства и запуск загрузчика операционной системы.

Для чего нужны драйверы? Драйверы должны поставляться производителями периферийных устройств. Они используются firmware для организации взаимодействия между устройством и UEFI приложением. С их помощью firmware может организовывать так называемые Runtime и Boot Services. Эти сервисы, в свою очередь, предоставляют набор функций, которые могут использовать UEFI приложения, сами драйверы, а так же загрузчик операционной системы.

Например, на сервере есть какой-то RAID контроллер с UEFI драйвером. Этот драйвер предоставляет базовые возможности доступа к содержимому своих RAID-массивов на блочном уровне через Boot Services. Т.е. например, загрузчик или какое-то другое UEFI приложение, используя определённые в спецификации API и протоколы, может прочитать информацию с тома RAID контроллера и, к примеру, выполнить загрузку ядра операционной системы. После загрузки ядро должно завершить работу с Boot Services и использовать свой полнофункциональный драйвер.

Другой пример - драйвер для сетевого адаптера может предоставить доступ к сети для загрузки операционной системы, либо для какого-то UEFI приложения, работающего с сетью. Эти драйверы могут предоставлять доступ к адаптеру не только в качестве Boot Services, но и как Runtime Services. Т.е. если у операционной системы нет драйвера для такого адаптера, то она может использовать стандартный API и продолжать работу с адаптером (на практике о таком использовании сетевых UEFI драйверов никто не слышал ;).

Вернёмся от драйверов к менеджеру загрузки. В его задачи входит выбор устройства загрузки и UEFI приложения в соответствии с настроенным порядком загрузки. Порядок определяется глобальными переменными из NVRAM, т.е. грубо говоря, настройками "BIOS". Например, если после инициализации UEFI firmware на сервере выбрать запуск меню настроек, то там отобразится список, порядок пунктов в котором будет выбран на основании этих самых глобальных переменных из NVRAM. В этом же списке могут оказаться дополнительные драйверы, загрузчики операционных систем, дополнительные UEFI приложения, найденные на EFI разделах дисков.

В спецификации UEFI в главе о таблице разделов GPT определены только два зарезервированных уникальных идентификатора GUID для типов разделов. Один из них используется для EFI System Partition. Этот раздел в таблице GPT используется для хранения дополнительных UEFI приложений, драйверов и загрузчиков операционных систем. Внутри этого раздела находится файловая система FAT с некоторыми дополнительными возможностями и требованиями. Сами же приложения представляют собой бинарники в формате PE/COFF (Microsoft Portable Executable and Common Object File Format).
Т.е. при желании можно смонтировать этот раздел и посмотреть, что там находится. Как, впрочем, и разместить там дополнительные приложения. Только необходимо поддерживать требуемую иерархию и именование файлов в файловой системе.

Дополнительные приложения могут выполнять самые разные функции. Например, это могут быть программы для диагностики оборудования, сетевые приложения, утилиты для работы с дисками и разделами, наконец - командный интерпретатор UEFI Shell.