FreeBSD mini-summit в Москве

В субботу 19-го ноября в Москве, в офисе компании Рамблер прошёл "русскоязычный FreeBSD mini-summit". Организация этого мероприятия произошла довольно спонтанно, буквально три недели назад во внутренней рассылке Глеб Смирнов предложил провести встречу, подобную той, что была летом в Киеве, и вот - собралось почти 30 человек. Кроме коммитеров FreeBSD на саммите были гости из NetBSD, а так же интересующиеся ребята из Яндекса, Рамблера и Вадим Гончаров :).

 Планировалось, что каждый участник расскажет о том, чем занимается в данное время и, возможно, будет подготовлено несколько докладов. Так же, в планах было провести некоторое время за "хаканьем" кода, но, к сожалению, я уже не успел на этом поприсутствовать.

Итак, немного о темах докладов и обсуждений.

Глеб Смирнов (glebius@) рассказал о новой реализации CARP, почему ему не нравилась старая, что уже сделано и что ещё предстоит сделать. Во время обсуждения прозвучало несколько интересных вопросов и предложений, которые, как мне показалось, Глеб взял на заметку. 

Лев Серебряков (lev@) рассказал о своих проектах по переработке кода модуля geom_raid5 и системе оповещения о событиях в geom.

Александр Черников (melifaro@) рассказал для чего нужен MPLS, об уже проделанной работе по реализации поддержки MPLS во FreeBSD и bird, о текущих проблемах в интерфейсах ядра, тормозящих разработку.

Андрей Пантюхин (sat@) рассказал о проблемах в нашей систем управления rc.d и пытался выяснить какими решениями пользуются присутствующие для обхода этих проблем.

Сергей Скворцов (skv@) выступил с докладом о некритичных, но усложняющих жизнь проблемах в системе портов и предложил варианты по их решению.

Игорь Сысоев (автор nginx) рассказал о проблемах во FreeBSD, мешающих ему, как разработчику высокопроизводительного сервера, а так же поделился мыслями о том, какие API  ему хотелось бы видеть во FreeBSD.

Руслан Ермилов (ru@) задал вопрос присутствующим - нужен ли нам проект по переводу man-страниц? Сошлись на том, что проект нужен, но для продолжения этой работы необходимы свежие силы. Причём как среди переводящих, так и среди редакторов, и рецензентов.

В целом, мероприятие прошло успешно, но, половины дня для такого количества человек всё же было маловато.

Ликбез по 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.

Отчёт: Август - Октябрь

Последнее время на блог всё не находилось времени. Завал на работе, командировки, проверки, комиссии, отмена перехода на зимнее время... В общем, хочу рассказать обо всём понемногу.

Во-первых, хочу ещё раз поздравить Александра Черникова с награждением коммит битом за его настойчивость в продвижении своих патчей :).

По причине отсутствия времени и заморозки кода коммитил мало. Глядя на архив почты можно отметить:

• добавление в man gpart секции BOOTSTRAPPING, посвящённой образам загрузочного кода, которые используется во FreeBSD с различными таблицами разделов;
• исправления в gpart(8), fdisk(8), boot0cfg(8);
• ликвидирована возможная в некоторых случаях паника в geom_part.

Что касается netmond, то всё что было "указано" в ТЗ - решено, заказчик доволен. Окончательную версию можно брать здесь.

Сейчас взялся за решение нескольких PR касающихся bsnmpd, в частности решил переделать реализацию доступа к информации о дисках и разделах в модуле hostres.

В geom_part_gpt была добавлена поддержка Boot Camp. Конфигурироваться из FreeBSD оно не может, но система может обнаруживать наличие Boot Camp и стараться не сломать его, если будут производиться какие-либо изменения в таблице GPT.

И ещё, после командировки заезжал в Москву, посетил офис Яндекса:

 

По внутреннему обустройству видно, что ребята живут на работе и им это нравится :)

netmond на FreeBSD amd64

Обращаюсь к тем, кто использует у себя в хозяйстве netmond. Если у вас есть возможность протестировать его работу на FreeBSD amd64, попробуйте вот эту версию. Из отличий от того, что есть в портах:

• включены патчи, которые идут отдельно к порту;
• теперь оно компилируется на amd64 без проблем;
• часть дублирующего базовые возможности системы кода удалена;
• убраны лишние зависимости.

От тестирования интересует на сколько сильно его работа отличается от того, как оно работало раньше (на amd64 замечены непонятные аномалии). Как оно ведёт себя на большом количестве объектов. Если кто-то попробует, буду благодарен за краткий отчёт мне на email.

Доступ к образам дисков VirtualBox из host системы

В списке рассылки freebsd-emulation был задан вопрос "как получить доступ к содержимому образа диска от VirtualBox?". Задача показалась мне интересной.

Немного погуглив нашёл вот такое описание формата. Прочитав его, немного покопался в исходниках VirtualBox и вот, за пару вечеров написал GEOM модуль для доступа к этим образам.

Модуль простенький, рассчитан он на одну версию метаданных (хотя добавить старые версии не сложно, но лень и не на чем тестировать), предоставляет доступ только для чтения. Код можно посмотреть здесь. Пользоваться просто - загружаете модуль, подключаете образ диска через mdconfig и, теоретически, он должен обнаружиться и для него будет создан провайдер с суффиксом .vdi. Примерно вот так:

# make 
# make load
/sbin/kldload -v /usr/home/butcher/work/vbox/mod/geom_vdi.ko
Loaded /usr/home/butcher/work/vbox/mod/geom_vdi.ko, id=5
# sysctl debug.bootverbose=1
debug.bootverbose: 0 -> 1
# mdconfig -f 10G_GPT_UFS.vdi
md0
GEOM_VDI: valid signature detected.
GEOM_VDI: Provider md0.vdi created.
# gpart show md0.vdi
=>      34  20971453  md0.vdi  GPT  (10G)
        34       256        1  freebsd-boot  (128k)
       290   2097152        2  freebsd-swap  (1.0G)
   2097442   4194304        3  freebsd-ufs  (2.0G)
   6291746  14679741        4  freebsd-ufs  (7G)

# geom vdi list
Geom name: md0.vdi
dataoffset: 41472
blocksoffset: 512
blockscount: 10240
blocksize: 1048576
mediasize: 10737418240
Providers:
1. Name: md0.vdi
   Mediasize: 10737418240 (10G)
   Sectorsize: 512
   Mode: r0w0e0
Consumers:
1. Name: md0
   Mediasize: 468754944 (447M)
   Sectorsize: 512
   Mode: r0w0e0

ipfw call / return

28 июня официально начался "Code Slush for 9.0-RELEASE", который так же известен как "Feature Freeze". Т.е. теперь в head/ бранч не разрешается вносить новый функционал. Цель этого мероприятия - стабилизировать состояние системы и сосредоточиться на поиске и исправлении ошибок. На 17-ое июля запланирован "Code Freeze" после которого последует выход первой бета версии FreeBSD 9.0.

Теперь о теме. Вадим Гончаров, узнав о предстоящем "Code Slush", выдал очередной патч для ipfw, который во что бы то ни стало должен оказаться в 9.0-RELEASE. :)
Патч добавляет два новых действия в ipfw: "call" и "return". Первая команда выполняет "вызов" подпрограммы, вторая - возврат из подпрограммы к следующему правилу. На практике, конечно, никаких подпрограмм не вызывается. Команда "call" принимает в качестве аргумента номер правила, к которому нужно выполнить переход. Переход осуществляется аналогично тому, как это делается для команды "skipto", только он может осуществляться в любом направлении по отношению к текущему правилу. Кроме того, перед выполнением перехода команда "call" сохраняет во внутреннем стеке номер своего правила в качестве точки возвращения. Размер стека ограничен 16 элементами. Это значит, что "подпрограмма" может содержать в себе другие вызовы "call" в другие "подпрограммы".
Возврат из "подпрограммы" осуществляется размещением правила с командой "return". У неё нет аргументов. Она находит в стеке первый элемент (по дисциплине LIFO), извлекает сохранённый номер правила и осуществляет возврат к следующему правилу с номером большим на 1.

Теперь о применении этого. Несомненно, есть несколько задач, в которых данный функционал может оказаться полезным. Но в то же время, скорость появления этого патча и практически полное отсутствие его тестирования ставит под сомнение плюсы, которые можно получить от него. Так что, если найдутся желающие на широких каналах протестировать этот функционал, было бы неплохо. Для этого, в общем-то, достаточно скачать образ 9.0-CURRENT и протестировать ;)

Кстати, Hiroki Sato сообщил о возобновлении сборки снепшотов FreeBSD CURRENT на ресурсе allbsd.org. Что является отличной новостью, для меня по крайней мере. Обычно для тестирования чего-либо бывает быстрее скачать образ и установить систему, чем обновляться из исходников.

Что нового?

Последние несколько недель в свободное время занимался обработкой открытых PR. В основном они были связаны с ipfw, dummynet и ipfw_nat, но не все. В общем, сократил количество открытых проблем где-то на полтора десятка, может даже на два. Считать, если честно - лень :)

Что хотелось бы отметить - это несколько исправлений и патчей, добавляющих новую функциональность. Желательно бы их получше оттестировать перед MFC. И, кстати говоря, вот уже почти неделю назад должен был начаться "code slush" в связи с подготовкой к выпуску 9.0-RELEASE.

Итак, первое исправление затрагивает kern/136695, kern/147720 и kern/150798. Связано оно с функцией форвардинга пакетов в ipfw и использованием динамических правил. Теперь реализация аналога reply-to из PF не должна составить труда и в ipfw (описание этого случая можно найти у Вадима Гончарова в блоге).

Следующее исправление связано с kern/122109, kern/129093 и kern/157379. Оно делает поведение ipfw_nat более похожим на natd. Возможно, те кто говорил, что ipfw_nat работает не так с правилами, с которыми работает natd, теперь вздохнут с облегчением. Теперь ipfw_nat будет более "гуманно" относится к пакетам, которые libalias не захотела обрабатывать. Раньше такие пакеты просто отбрасывались, что приводило к симптомам, хорошо показанным в перечисленных PR.

Теперь о новом функционале в ipfw_nat - kern/157867. Это аналог опции globalport для natd. Если у вас сконфигурировано несколько NAT'ов, то теперь можно одним правилом заставить ipfw проверять пакет сразу для всех таблиц трансляций. Для этого добавлено новое "кодовое слово"- nat global. Пакет будет обрабатываться в соответствии с конфигурацией той таблицы, в которой найдётся подходящее состояние.


В модуль libalias, обрабатывающий FTP соединения внесены изменения kern/157957, благодаря которым он корректно работает при использование опции redirect_port для ipfw_nat. Кстати, Глеб Смирнов изменил обработку опций NAT для ipfw(8). Теперь командная строка не ограничена длиной NAT_BUF_LEN и при настройках NAT можно указывать сколько угодно опций.

Кроме того, для ipfw setfib добавлена поддержка tablearg - kern/156410.

Еще было несколько мелких исправлений, которые не так интересны. Но в общем, за большинство из этих изменений и исправлений можно поблагодарить Александра Черникова. Именно у него хватило терпения и желания, копаться в коде, который местами далеко не очевиден, писать патчи и продвигать их, чтобы они оказались в системе.

Да, ещё. По проблеме с загрузкой с ZFS. Вчера John Baldwin добавил исправление в загрузочный код, которое, вероятно исправит большинство проблем.