DragonflyBSD -- "стрекоза с рожками"

Нечасто в последнее время разработчики балуют нас чем-то очень интересным. И, тем более, -- принципиально новым. В сущности, ничего плохого в этом нет -- индустрия программного обеспечения становится фактически "традиционной" и к "взрывным" событиям относится настороженно. И все-таки специфический характер интеллектуальной продукции не может не сказываться...

Как уже принято среди некоммерческих (или, если хотите, "альтернативных") разработчиков, любой новый проект должен получить удачный символ талисман (mascot). В перечне самых популярных талисманов представители животного мира занимают не последнее место -- например, антилопа гну (проект GNU) и пингвин (проект Linux). Есть и не менее знаменитые символы, не заимствованные у Природы, -- такие как дэй-моны (ни в коем случае не "демоны", талисманы *BSD). А вот насекомых почему то разработчики недолюбливали. Возможно, это связано с какими нибудь загадочными фобиями -- не станем гадать. Лучше давайте сделаем очень короткое отступление, неимоверно далекое от сухого стиля технического еженедельника.

Вы еще помните, как в детстве с восторгом следили за стрекозами? Как пробовали их ловить? Помните чудеса, которые способны творить в воздухе эти крохотные совершенства? Повзрослев, при желании можно было узнать о стрекозах совсем неожиданное -- их "система управления" на удивление проста. Поразительное -сочетание элементарной нервной -системы и феноменальных "летных характеристик" -- вот такое это су-щество...

Уже понятно, что стрекоза -- талисман символ нового проекта DragonflyBSD, стартовавшего всего лишь год назад. Правда, за этот год команде разработчиков удалось добиться очень многого -- первый релиз--кандидат системы уже доступен для всех желающих и включает реализации ключевых идей, о которых говорит его название. И если вы решили, что дальше материал читать не следует (что абсолютно понятно -- подумаешь, еще одна Unix совместимая операционная система, как будто их кому то не хватает), не торопитесь. Dragon-flyBSD -- совершенно новая ОС. Таких еще не было. Возможно, это та самая "свежая кровь", в которой так нуждается прошедшая более 30 лет экстенсивного развития ОС Unix. Может быть, это реинкарнация пресловутого "пути Unix" (Unix way): от простоты -- к совершенству. В общем, вам судить, хотя судить здесь будет непросто. Ведь "внешне", на пользовательском уровне, Dra-gon-flyBSD практичес--ки ничем не отличается от своих Unix совместимых родственниц. Принципиальная новизна данной системы вынужденно скрыта под традиционным Unix окружением ("вынужденно" использовано не случайно -- вспомните печальную судьбу за-мечательной ОС Atheos...).

Лица, мотивы, цели

I don't think it's (DragonflyBSD -- Прим. автора)
anyone's design in particular, but I tend to sit down
and write things from scratch rather then copy
other people's ideas.
Matthew Dillon

Сразу оговоримся, эпиграф умышленно оставлен пока без перевода. Так что если вы в неладах с английским языком, не спешите тянуться за словарем -- всему свое время.

16 июля 2003 года один из разработчиков ОС FreeBSD Мэтью Диллэн в почтовых рассылках проекта объявил о старте "нового ответвления" в развитии этой операционной системы. В качестве базового кода Диллэн выбрал, как ни странно, очень стабильную, но во многом архаичную ветвь FreeBSD 4.x, тогда как все новые веяния сосредоточены в 5.x. Выбор классической базовой BSD архитектуры вместо неоклассической -- исклю-чительно важный нюанс для понимания целей проекта DragonflyBSD. Настолько важный, что для его дальнейшего обсуждения мы приведем мнения, которые высказываются по ту сторону баррикад.

На прошлой неделе достойнейший представитель лагеря Windows, признанный специалист в области современных операционных систем, Марк Руссинович (по совместительству -- главный системный архитектор компании Winternals Software и соавтор культовой книги "Inside Windows 2000") несколько неожиданно выступил на конференции Microsoft TechEd в Амстердаме. Он говорил даже не о техническом сближении, а о сходствах между ядрами самых противопоставляемых ОС современности -- Linux и Windows. Выступление было достаточно технически насыщенным, поэтому пока мы воспользуемся только его выводами: начиная с ядра 2.6, Linux по функциональным системным возможностям стала практически идентичной детищу Дэвида Катлера (David Cutler, архитектор ядер ОС DEC VMS и Windows NT). По авторитетному мнению Руссиновича, повторная входимость (или реентерабельность) ядра Linux 2.6 стерла последние принципиальные различия в системной части этих ОС и сместила фронты "великой войны" (всегда сдержанный Руссинович, естественно, так не говорил) в пользовательскую область. Впрочем, войны нас не привлекают. Нам больше интересно, какой ценой достигнут текущий паритет. Ядро Linux 2.6 к моменту анонса насчитывало около 4,2 млн. строк кода -- мягко сказать, гнетущее число (сведение о том, что порядка 50% кода ядра -- это фактически "драйверный код", ситуации не улучшает). Судите сами, по данным Гэри МакГроу (CTO компании Cigital, специализирующейся на управлении качеством в процессе разработки ПО), ОС Windows 2000 насчитывает 35 млн. строк кода, Windows XP -- 40 млн. Но эти ОС включают в себя не только ядро, но и колоссальный набор масштабных программных комплексов системного и пользовательского уровней -- только интегрированные в Windows компоненты Internet Explorer "заменяются" в Linux более чем 2 млн. строк кода Mozilla. Так что 4,2 млн. строк только ядра ОС -- это очень и очень немало. Теперь добавим к данному соображению сведения о динамике роста ядра Linux:

DragonflyBSD -- "стрекоза с рожками"

Как видите, рост фактически экспоненциальный. И это расплата за совершенство. Хотя бы потому, что он означает и экспоненциальный рост как сложности его сопровождения, так и "имплантации" принципиально новых, архитектурных модификаций. В подтверждение можно привести оценки еще одного признанного специалиста Дэвида Уилера (David A. Wheeler): стоимость разработки дистрибутива (на сегодняшний день устаревшего) RedHat 7.1 эквивалентна более чем 1 млрд. долларов и 8 тысячам человеко лет при коммерческой организации проектного процесса, при этом версия 7.1 демонстрирует 60%-ный рост эквивалентных затрат по сравнению со своей предшественницей -- RedHat 6.2. По сути, такой же закономерности подчинена любая разработка, которая усовершенствуется своими создателями в рамках одной архитектурной традиции. И начиная с некоторого значения масштаба неизбежно наступает момент истины, когда лучше и проще (во всех отношениях) "что то в консерватории исправить".

Вот теперь настало время вернуться к выбору Диллэном в качестве опорной точки классического ядра FreeBSD 4.x и к оставленному без перевода эпиграфу. "Я не думаю, что дизайн DragonflyBSD принадлежит кому либо конкретно; я предпочитаю создавать что то "с нуля", а не копировать идеи других людей", -- так сказал о себе Мэтью Диллэн. Впрочем, давайте немного уточним -- Диллэн прошел серьезную школу одной из лучших пользовательских платформ прошлого -- Amiga (для которой создал, в частности, известный C-компилятор DICE), он является автором обновленных систем управления виртуальной памятью и свопингом ОС FreeBSD (Диллэн устранил множество ошибок в коде ядра этой ОС), а также до сих пор использующегося в различных Unix сов-местимых системах планировщика задач Dcron. Этот опыт, несомненно, сказался -- и в том, что DragonflyBSD во многих идеях неуловимо схожа с классической AmigaOS, и, как ни странно, в том, что Диллэн очень хорошо умеет работать в условиях open source сообщества. Последнее весьма немаловажно -- вопреки расхожему мнению, такая работа далека от идиллически лубочных картинок, рисующих умных добрых бородатых друзей, сплоченных общим делом, на фоне красивых компьютеров. Чтобы пояснить, о чем идет речь, приведем высказывание самого Диллэна об опыте создания и сопровождения программы Dcron: "Мне приятно видеть, что она до сих пор регулярно используется, но я раздосадован тем, что никто не приложил усилий для какого то ее усовершенствования. Наверное, такова природа open sour-ce". Ну и вторая составляющая специфики работы -- естественно, психологическое давление, оказываемое на ярких самостоятельных разработчиков со стороны наиболее агрессивных (и многочисленных) членов "противостоящих комьюнити".

Все эти мелкие детали на самом деле не так уж и незначительны -- в некоммерческих проектах, где нет финансовой заинтересованности разработчиков и где трудно приобрести знаменитость, умение продуктивно работать в весьма специфической среде -- одно из главных условий успеха.

Теперь вернемся к обсуждаемому выбору "кодовой базы" проекта. "Система DragonflyBSD началась как ветвь FreeBSD 4.x потому, что это была наиболее надежная и отработанная стартовая точка и потому что мы хотели реализовать ключевые части системы радикально отличающимися от принятого в проекте FreeBSD 5.x направления... Кроме того, кодовая база FreeBSD 4.x строго ограничена в отношении существенных модификаций кода (иначе говоря, является стабильной кодовой базой -- Прим. автора)". Что сказать -- выбор стабильной и фактически подошедшей к концу жизненного цикла FreeBSD 4.x совершенно логичен, особенно если учесть тот факт, что ядро новой ветви 5.x подвержено действию той же закономерности, что и ядро Linux (некоторым техническим подробностям, объясняющим, почему так происходит, будет уделено внимание в третьей части статьи). Ну а цель, как говорилось ранее, -- вернуть Unix подобные системы на тот путь эволюции, в результате которого должна появиться "стрекоза" -- одновременно такая простая и такая совершенная.

Для полноценного знакомства осталось, пожалуй, сказать пару слов о ресурсах, которыми располагает проект. Более 240 человек в той или иной мере участвуют в разработке ядра ОС, открыта компания, обеспечивающая коммерческое сопровождение дистрибутива под названием SilverOS, основанного на DragonflyBSD.

Другая Unix

Что же принципиально нового в практически неотличимой глазами пользователя DragonflyBSD? Проще всего на это вопрос ответить кратко -- почти все. "Почти" потому, что новизна упрятана не столько за традиционным видом, сколько за традиционным Unix API, правда, "стрекоза" создавалась изначально с таким расчетом, что прослойку, обеспечивающую API, можно "подстегивать" без особых проблем. И все таки давайте по порядку.

Наибольшую сложность при мо-дификациях кода классических Unix ядер разработчики практически всех ОС испытывают при реализации эффективной поддержки мультипроцессорных систем. В Linux и FreeBSD 5.x для этой цели в неоклассических ядрах применяется модель взаимного исключения (сокращенное общепринятое название -- mutex), позволяющая избежать главной проблемы параллельного программирования -- одновременного использования одних и тех же неразделяемых ресурсов разными фрагментами кода (такие потенциально опасные фрагменты называются критическими секциями). Под неразделяемыми ресурсами здесь понимаются разнообразные конструкции, использующиеся для взаимодействия между программами--обработчиками прерываний и "остальными программами", т. е. одни из ключевых ресурсов любой ОС. Для решения задачи синхронизации доступа к ним часто применяются программные флаги "блокировки", в которых захвативший доступ к ресурсу код оставляет предупреждение "занято" всем возможным претендентам. Очевидно, что чем меньшие фрагменты кода ядра ОС являются критическими секциями, тем большей степени "параллелизма" можно добиться при эксплуатации такой ОС на мультипроцессорной машине. И также очевидно, что решение подобной задачи далеко не простое... В отличие от неоклассических ядер Linux и FreeBSD 5.x в DragonflyBSD "блокировки" отсутствуют принципиально -- потому как система не базируется на модели взаимного исключения. Ее архитектурная основа -- легковесные потоки (нити) ядра, LWKT (потоки выполнения, не имеющие собственного контекста "тяжелого" процесса). При этом вместо одного общего планировщика задач (scheduler) в ОС для мультипроцессорных систем в Dragon-flyBSD применяется несколько -- по числу процессоров. Каждый scheduler каждого процессора отвечает только за то, что ему подвластно -- в данном случае остается единственная критическая секция кода, локальная по отношению к процессору, а не ко всей мультипроцессорной системе в целом (причем это действительно элементарный код -- увеличения/уменьшения на единицу значения одной переменной). Такая архитектура, естественно, предусматривает возможность передачи потока выполнения с одного процессора на другой -- но не автоматически, а исключительно по требованию потока, что справедливо только для потоков, выполняющихся в пользовательском режиме ОС. Не следует воспринимать это как ограничение -- в DragonflyBSD таким образом выводится максимум кода ядра (в первую очередь, драйверы устройств) в пользовательский режим. Данная трансформация одновременно обеспечивает и рост производительности системы (чем больше в ней "пользовательских драйверов", тем, грубо говоря, выше асинхронность всей системы в целом), и надежность -- падение драйвера, выполняющегося в пользовательском режиме, не приводит к фатальным для системы последствиям. И наконец, у этой медали есть и третья, архитектурная, сторона -- "драйверы пользовательского режима" дают как реальную возможность унифицировать их программные интерфейсы (что означает отсутствие необходимости модификаций кода ядра ОС при добавлении драйверов), так и применить принцип виртуализации физических устройств. Очевидно, что реализация всех этих технологических "вкусностей" была бы невозможна без фундаментальных изменений в архитектуре классического монолитного ядра Unix совместимой ОС. И таким фундаментальным изменением здесь является отказ от традиционных вызовов подпрограмм в пользу асинхронного механизма передачи сообщений, что сближает DragonflyBSD с микроядерными системами -- именно сближает, но не больше. В идеале, вся система -- до уровня эмуляции Unix API -- будет основана на механизме сообщений, что существенно упрощает, например, реализацию поддер-жки потоков пользовательского режима ядром ОС. Целостность концепции Dragon-flyBSD обеспечивается и радикальным изменением одного из самых сложных и важных механизмов ядра любой Unix совместимой ОС -- виртуальной файловой системы (VFS). Здесь в "стрекозе" изменяется практически все, что можно изменить -- VFS вместо сложнейшей реентерабельной (повторно входимой) программы превращается в сервер сообщений, полностью перестраиваются политики кэширования, значительная часть кода переводится в пользовательский режим. В общем, это уже совсем не та VFS, без существенных преобразований дошедшая до сегодняшнего дня.

Не обошлось в DragonflyBSD и без модификации подсистемы выделения памяти ядра -- в ней использован slab allocator, реализация которого, в силу архитектурной специфики, в три раза компактнее аналога, например применяемого во FreeBSD 5.x. Кроме этого, по аналогии с AmigaOS "стрекоза" обладает возможностью сокращения времени запуска больших программ, задействующих множество динамических библиотек (что достигается созданием "снимка" на диске задействованной виртуальной памяти программы и повторным его использованием при новых за-пусках).

Из наблюдаемых невооруженным глазом изменений следует отметить "вариантные символические ссыл-ки" файлов, специально реализованные для нужд будущей системы управления пакетами DragonflyBSD (пока в ней применяется унаследованный от FreeBSD 4.x аналог). Вариантная символическая ссылка -- varsyms -- весьма специфическая разновидность традиционной символической ссылки, позволяющая упрятывать в ее имени изменяемую, например из скриптов командного интерпретатора, информацию. По умолчанию varsyms локальны для пользователя, но команда их создания предусматривает как расширение локализации (до уровня всей системы), так и ограничение (до уровня процесса).

В завершение...

"Стрекоза" не нацелена ее разработчиками на какую то конкретную область применения, потому должна неплохо чувствовать себя и в качестве ОС рабочей станции, и, тем более, на мультипроцессорном сервере. Умения Диллэна как управленца и системного архитектора, завидная производительность команды и, наконец, стремление создать нечто новое -- одновременно простое и эффективное, не могут не вызывать искренней симпатии. Однако как бы ни сложилась дальнейшая судьба DragonflyBSD, проект свое слово уже фактически сказал -- идея LWKT заимствуется командой OpenBSD, не исключено и ее влияние на прародительницу -- FreeBSD. И все таки, пусть будет больше систем, хороших и лучших...

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365