DragonFly BSD — это бесплатная Unix-подобная операционная система с открытым исходным кодом , созданная на основе FreeBSD 4.8. Мэтью Диллон , разработчик Amiga в конце 1980-х и начале 1990-х годов и разработчик FreeBSD в период с 1994 по 2003 год, начал работу над DragonFly BSD в июне 2003 года и объявил о ней в списках рассылки FreeBSD 16 июля 2003 года .
Диллон основал DragonFly, полагая, что методы, используемые для многопоточности и симметричной многопроцессорной обработки во FreeBSD 5 [5] , приведут к снижению производительности и проблемам с обслуживанием. Он стремился исправить эти ожидаемые проблемы в рамках проекта FreeBSD. [6] Из-за конфликтов с другими разработчиками FreeBSD по поводу реализации его идей, [7] его возможность напрямую изменять кодовую базу в конечном итоге была лишена. Несмотря на это, проекты DragonFly BSD и FreeBSD по-прежнему работают вместе, обмениваясь исправлениями ошибок, обновлениями драйверов и другими улучшениями.
Задуманный как логическое продолжение серии FreeBSD 4.x, DragonFly значительно отличается от FreeBSD, реализуя облегченные потоки ядра (LWKT), систему передачи сообщений внутри ядра и файловую систему HAMMER . [8] На многие концепции дизайна повлияла AmigaOS . [9]
Разрабатываемая подсистема обмена сообщениями ядра аналогична тем, которые используются в микроядрах, таких как Mach , хотя по конструкции она менее сложна. Подсистема обмена сообщениями DragonFly способна действовать как синхронно, так и асинхронно и пытается использовать эту возможность для достижения максимально возможной производительности в любой конкретной ситуации. [10]
По словам разработчика Мэтью Диллона , достигнут прогресс в обеспечении возможностей ввода/вывода устройств (I/O) и обмена сообщениями виртуальной файловой системы (VFS), что позволит достичь остальных целей проекта. Новая инфраструктура позволит перенести многие части ядра в пользовательское пространство; здесь их будет легче отлаживать, поскольку они будут меньшими изолированными программами, а не небольшими частями, переплетенными в более крупный фрагмент кода. Кроме того, миграция избранного кода ядра в пользовательское пространство делает систему более надежной; если произойдет сбой драйвера пользовательского пространства, это не приведет к сбою ядра. [11]
Системные вызовы разделяются на версии пользовательского пространства и ядра и инкапсулируются в сообщения. Это поможет уменьшить размер и сложность ядра за счет перемещения вариантов стандартных системных вызовов на уровень совместимости пользовательской среды и поможет поддерживать прямую и обратную совместимость между версиями DragonFly. Код совместимости Linux и других Unix-подобных ОС переносится аналогичным образом. [9]
Поскольку поддержка архитектур с несколькими наборами команд усложняет поддержку симметричной многопроцессорной обработки (SMP), [7] DragonFly BSD теперь ограничивает свою поддержку платформой x86-64 . [12] Изначально DragonFly работал на архитектуре x86 , однако начиная с версии 4.0 она больше не поддерживается. Начиная с версии 1.10, DragonFly поддерживает потоки пользовательского пространства 1:1 (один поток ядра на каждый поток пользовательского пространства), [13] что считается относительно простым решением, которое также легко поддерживать. [9] DragonFly, унаследованный от FreeBSD, также поддерживает многопоточность. [14]
В DragonFly каждый процессор имеет собственный планировщик потоков. При создании потоки назначаются процессорам и никогда не переключаются с одного процессора на другой заранее; они переносятся только путем передачи сообщения межпроцессорного прерывания (IPI) между участвующими процессорами. Межпроцессорное планирование потоков также осуществляется путем отправки асинхронных сообщений IPI. Одним из преимуществ такого четкого разделения подсистемы потоков является то, что встроенные кэши процессоров в симметричных многопроцессорных системах не содержат дублированных данных, что позволяет повысить производительность за счет предоставления каждому процессору в системе возможности использовать свой собственный кэш для хранения различных данных. вещи, над которыми нужно работать. [9]
Подсистема LWKT используется для разделения работы между несколькими потоками ядра (например, в сетевом коде имеется один поток на каждый протокол и процессор), что снижает конкуренцию за счет устранения необходимости совместного использования определенных ресурсов между различными задачами ядра. [7]
Для безопасной работы на многопроцессорных машинах доступ к общим ресурсам (таким как файлы, структуры данных) должен быть сериализован , чтобы потоки или процессы не пытались одновременно изменить один и тот же ресурс. Чтобы предотвратить одновременный доступ нескольких потоков к общему ресурсу или его изменение, DragonFly использует критические секции и сериализует токены для предотвращения одновременного доступа. В то время как Linux и FreeBSD 5 используют детализированные модели мьютексов для достижения более высокой производительности в многопроцессорных системах, DragonFly этого не делает. [7] До недавнего времени DragonFly также использовал spls , но они были заменены критическими секциями.
Большая часть ядра системы, включая подсистему LWKT , подсистему обмена сообщениями IPI и новый распределитель памяти ядра, не имеет блокировок, что означает, что они работают без использования мьютексов, при этом каждый процесс работает на одном процессоре. Критические секции используются для защиты от локальных прерываний индивидуально для каждого процессора, гарантируя, что исполняемый в данный момент поток не будет вытеснен. [13]
Токены сериализации используются для предотвращения одновременного доступа со стороны других процессоров и могут удерживаться одновременно несколькими потоками, гарантируя, что в любой момент времени работает только один из этих потоков. Таким образом, заблокированные или спящие потоки не препятствуют доступу других потоков к общему ресурсу, в отличие от потока, удерживающего мьютекс. Помимо прочего, использование сериализации токенов предотвращает многие ситуации, которые могут привести к взаимоблокировкам и инверсиям приоритетов при использовании мьютексов, а также значительно упрощает разработку и реализацию многоэтапной процедуры, которая потребует совместного использования ресурса между несколько потоков. Код токена сериализации развивается во что-то очень похожее на функцию « Чтение-копирование-обновление », доступную теперь в Linux. В отличие от текущей реализации RCU в Linux, реализация DragonFly реализована таким образом, что затрагиваются только процессоры, конкурирующие за один и тот же токен, а не все процессоры в компьютере. [15]
DragonFly перешел на мультипроцессорный безопасный slab-аллокатор , который не требует ни мьютексов, ни операций блокировки для задач распределения памяти. [16] В конечном итоге он был перенесен в стандартную библиотеку C в пользовательском пространстве, где заменил реализацию malloc во FreeBSD. [17]
Начиная с версии 1.8 DragonFly имеет механизм виртуализации, аналогичный пользовательскому режиму Linux , [18] позволяющий пользователю запускать другое ядро в пользовательском пространстве. Виртуальное ядро ( vkernel ) запускается в полностью изолированной среде с эмулируемыми интерфейсами сети и хранилища, что упрощает тестирование подсистем ядра и функций кластеризации. [9] [11]
У vkernel есть два важных отличия от реального ядра: в нем отсутствуют многие процедуры для низкоуровневого управления оборудованием, и там, где это возможно, вместо встроенных реализаций используются функции стандартной библиотеки C (libc). Поскольку как реальное, так и виртуальное ядро компилируются из одной и той же базы кода, это фактически означает, что зависящие от платформы подпрограммы и повторные реализации функций libc четко разделены в дереве исходного кода. [19]
vkernel работает поверх аппаратных абстракций, предоставляемых реальным ядром. К ним относятся таймер на основе kqueue , консоль (сопоставленная с виртуальным терминалом , где выполняется vkernel), образ диска и Ethernet-устройство виртуального ядра ( VKE ), туннелирующее все пакеты к ответвительному интерфейсу хоста . [20]
Стороннее программное обеспечение доступно на DragonFly в виде двоичных пакетов через pkgng
или из собственной коллекции портов — DPorts . [21]
Первоначально DragonFly использовала коллекцию портов FreeBSD в качестве своей официальной системы управления пакетами , но начиная с версии 1.4 перешла на систему pkgsrc NetBSD , что воспринималось как способ уменьшения объема работы, необходимой для доступности стороннего программного обеспечения. [6] [22] В конце концов, поддержание совместимости с оказалось требующим больше усилий, чем первоначально предполагалось, поэтому в рамках проекта был создан DPorts, надстройка над коллекцией портов FreeBSD . [23] [24]pkgsrc
Первоначальная реализация протокола Common Address Redundancy Protocol (обычно называемого CARP ) была завершена в марте 2007 года . [25] С 2011 года поддержка CARP интегрирована в DragonFly BSD. [26]
Наряду с файловой системой Unix , которая обычно является файловой системой по умолчанию в BSD, DragonFly BSD поддерживает файловые системы HAMMER и HAMMER2 . HAMMER2 является файловой системой по умолчанию начиная с версии 5.2.0.
HAMMER был разработан специально для DragonFly BSD, чтобы предоставить многофункциональный, но улучшенный аналог набирающей популярность ZFS . [9] [11] [27] HAMMER поддерживает настраиваемую историю файловой системы, снимки , контрольную сумму , дедупликацию данных и другие функции, типичные для файловых систем такого типа. [18] [28]
HAMMER2, преемник файловой системы HAMMER, теперь считается стабильной, используется по умолчанию и находится в центре дальнейшего развития. Планы по его разработке были первоначально обнародованы в 2012 году. [29] В 2017 году Диллон объявил, что следующая версия DragonFly BSD (5.0.0) будет включать в себя пригодную к использованию, хотя и все еще экспериментальную, версию HAMMER2, и описал особенности конструкции. [30] С выпуском после 5.0.0 версии 5.2.0 HAMMER2 стала новой файловой системой по умолчанию.
В 2007 году DragonFly BSD получила новую файловую систему устройств (devfs), которая динамически добавляет и удаляет узлы устройств, позволяет получать доступ к устройствам по путям подключения, распознает диски по серийным номерам и устраняет необходимость в предварительно заполненной /dev
иерархии файловой системы. Он был реализован как проект Google Summer of Code 2009. [31]
DragonFly BSD поддерживает функцию резидентных приложений в стиле Amiga : после загрузки он делает снимок пространства виртуальной памяти большой, динамически связанной программы , что позволяет будущим экземплярам программы запускаться гораздо быстрее, чем в противном случае. Это заменяет возможность предварительного связывания , над которой работали ранее в истории проекта, поскольку резидентная поддержка намного более эффективна. Большие программы, подобные тем, что есть в компиляции программного обеспечения KDE со многими общими библиотеками, больше всего выиграют от этой поддержки. [32]
Как и в случае с FreeBSD и OpenBSD , разработчики DragonFly BSD постепенно заменяют код C в стиле прототипа предварительной функции более современными эквивалентами ANSI . Подобно другим операционным системам, версия коллекции GNU Compiler Collection от DragonFly имеет усовершенствование, называемое Stack-Smashing Protector (ProPolice) , включенное по умолчанию, обеспечивающее некоторую дополнительную защиту от атак, основанных на переполнении буфера . По состоянию на 23 июля 2005 г. ядро больше не имеет этой защиты по умолчанию. [32][обновлять]
Будучи производной от FreeBSD, DragonFly унаследовала простую в использовании интегрированную систему сборки, которая может пересобрать всю базовую систему из исходного кода с помощью всего лишь нескольких команд. Разработчики DragonFly используют систему контроля версий Git для управления изменениями исходного кода DragonFly . В отличие от своей родительской FreeBSD, DragonFly имеет как стабильные, так и нестабильные версии в одном дереве исходного кода из-за меньшей базы разработчиков. [7]
Как и другие ядра BSD (и большинства современных операционных систем), DragonFly использует встроенный отладчик ядра , который помогает разработчикам находить ошибки ядра. Более того, с октября 2004 года [обновлять]по умолчанию устанавливается отладочное ядро, которое делает отчеты об ошибках более полезными для отслеживания проблем, связанных с ядром, за счет относительно небольшого количества дискового пространства. При установке нового ядра из резервной копии предыдущего ядра и его модулей удаляются символы отладки, чтобы еще больше минимизировать использование дискового пространства.
Операционная система распространяется в виде Live CD и Live USB , с которых загружается полная система DragonFly. [18] [31] Он включает в себя базовую систему и полный набор страниц руководства, а также может включать исходный код и полезные пакеты в будущих версиях. Преимущество этого заключается в том, что с помощью одного компакт-диска пользователи могут установить программное обеспечение на компьютер, использовать полный набор инструментов для восстановления поврежденной установки или продемонстрировать возможности системы без ее установки. Ежедневные снимки доступны на главном сайте для тех, кто хочет установить самые последние версии DragonFly без сборки из исходного кода.
Как и другие бесплатные BSD с открытым исходным кодом, DragonFly распространяется на условиях современной версии лицензии BSD .
HAMMER действительно кажется очень интересной файловой системой BSD.
Хотя она и не так быстра, как файловая система ZFS в BSD, но это также оригинальная файловая система для проекта DragonFlyBSD, а не порт из OpenSolaris.
HAMMER не только в целом быстрее обычной файловой системы UFS, но и имеет гораздо больший набор функций.