Загрузчик DragonFly BSD 4.2.3 | |
Разработчик | Мэтью Диллон |
---|---|
Семейство ОС | Unix-like |
Рабочее состояние | Текущая |
Исходная модель | Открытый исходный код |
Первоначальный выпуск | 1.0 / 12 июля 2004 г.; 16 лет назад (2004-07-12) |
Последний выпуск | 5.8.3 / 24 сентября 2020 г.; 22 дня назад (2020-09-24) |
Репозиторий | |
Доступен на | английском |
Диспетчер пакетов | pkg |
Платформы | x86-64 |
Kernel type | Hybrid |
Userland | BSD |
Default пользовательский интерфейс | Unix shell |
Лицензия | BSD |
Официальный сайт | www.dragonflybsd.org |
DragonFly BSD является бесплатным и открытым исходным кодом Unix-подобная операционная система разветвлена из FreeBSD 4.8. Мэтью Диллон, разработчик Amiga в конце 1980-х - начале 1990-х и разработчик FreeBSD в период с 1994 по 2003 год, начал работать над DragonFly BSD в июне 2003 года и объявил об этом в списках рассылки FreeBSD на 16 июля 2003 г.
Диллон основал DragonFly, полагая, что методы, принятые для многопоточности и симметричной многопроцессорной обработки во FreeBSD 5, приведут к снижению производительности и проблемам с обслуживанием. Он стремился исправить эти ожидаемые проблемы в рамках проекта FreeBSD. Из-за конфликтов с другими разработчиками FreeBSD по поводу реализации его идей, его способность напрямую изменять кодовую базу была в конечном итоге лишена. Несмотря на это, проекты DragonFly BSD и FreeBSD по-прежнему работают вместе, делясь исправлениями ошибок, обновлениями драйверов и другими улучшениями.
Задуманный как логическое продолжение серии FreeBSD 4.x, DragonFly значительно отличается от FreeBSD, реализовав облегченные потоки ядра (LWKT), передачу сообщений внутри ядра и файловая система HAMMER . AmigaOS.
Разрабатываемая подсистема обмена сообщениями ядра аналогична найденным в микроядрах, таких как Mach, хотя он менее сложен по конструкции. Однако DragonFly использует монолитную систему ядра. Подсистема обмена сообщениями DragonFly может работать в синхронном или асинхронном режиме и пытается использовать эту возможность для достижения наилучшей производительности в любой конкретной ситуации.
По словам разработчика Мэтью Диллона, ведется работа по обеспечению возможностей обмена сообщениями как устройства ввода / вывода (I / O), так и виртуальной файловой системы (VFS), которые позволят достичь оставшихся целей проекта. Новая инфраструктура позволит перенести многие части ядра в пользовательское пространство; здесь их будет легче отлаживать, поскольку они будут меньшими по размеру изолированными программами, а не маленькими частями, вплетенными в большой кусок кода. Кроме того, перенос выбранного кода ядра в пользовательское пространство дает преимущество в повышении надежности системы; если произойдет сбой драйвера пользовательского пространства, это не приведет к сбою ядра.
Системные вызовы разделяются на версии пользовательского пространства и ядра и инкапсулируются в сообщения. Это поможет уменьшить размер и сложность ядра за счет перемещения вариантов стандартных системных вызовов на уровень совместимости пользователя и поможет поддерживать прямую и обратную совместимость между версиями DragonFly. Linux и другие Unix-подобные коды совместимости с ОС переносятся аналогичным образом.
Как поддержка нескольких архитектур наборов инструкций усложняет поддержку симметричной многопроцессорной обработки (SMP), теперь DragonFly BSD поддерживает только платформу x86-64. Изначально DragonFly работал на архитектуре x86, однако с версии 4.0 она больше не поддерживается. Начиная с версии 1.10, DragonFly поддерживает потоки пользовательской среды 1: 1 (один поток ядра на поток пользовательской среды), что считается относительно простым решением, которое также легко поддерживать. Унаследованный от FreeBSD, DragonFly также поддерживает многопоточность.
В DragonFly каждый CPU имеет свой собственный планировщик потоков. После создания потоки назначаются процессорам и никогда не переключаются с одного процессора на другой заранее; они переносятся только путем передачи сообщения межпроцессорного прерывания (IPI) между задействованными ЦП. Планирование межпроцессорных потоков также выполняется путем отправки асинхронных сообщений IPI. Одним из преимуществ такого чистого разделения подсистемы потоковой обработки является то, что встроенные кэши процессоров в симметричных многопроцессорных системах не содержат дублированных данных, что обеспечивает более высокую производительность, предоставляя каждому процессору в система может использовать свой собственный кеш для хранения различных вещей, над которыми можно работать.
Подсистема LWKT используется для разделения работы между несколькими потоками ядра (например, в сетевом коде там - один поток на протокол на процессор), что снижает конкуренцию за счет устранения необходимости разделять определенные ресурсы между различными задачами ядра.
Для безопасной работы на многопроцессорных машинах доступ к общие ресурсы (например, файлы, структуры данных) должны быть сериализованы, чтобы потоки или процессы не пытались одновременно изменять один и тот же ресурс. Чтобы предотвратить одновременный доступ или изменение общего ресурса несколькими потоками, DragonFly использует критические секции и сериализует токены для предотвращения одновременного доступа. Хотя и Linux, и FreeBSD 5 используют детализированные модели мьютекса для достижения более высокой производительности в многопроцессорных системах, DragonFly этого не делает. До недавнего времени DragonFly также использовал spls, но они были заменены критическими секциями.
Большая часть ядра системы, включая подсистему LWKT, подсистему обмена сообщениями IPI и новый распределитель памяти ядра, не заблокированы, что означает, что они работают без использования мьютексов, причем каждый процесс работает на одном процессоре. Критические секции используются для защиты от локальных прерываний, индивидуально для каждого ЦП, гарантируя, что поток, выполняемый в данный момент, не будет вытеснен.
Сериализационные токены используются для предотвращения одновременного доступа с других ЦП и могут удерживаться одновременно несколько потоков, гарантируя, что только один из этих потоков работает в любой момент времени. Таким образом, заблокированные или спящие потоки не препятствуют доступу других потоков к общему ресурсу, в отличие от потока, который удерживает мьютекс. Среди прочего, использование токенов сериализации предотвращает многие ситуации, которые могут привести к взаимоблокировкам и инверсии приоритета при использовании мьютексов, а также значительно упрощает разработку и реализацию многих -шаговая процедура, которая требует, чтобы ресурс разделялся между несколькими потоками. Код сериализуемого токена развивается во что-то очень похожее на функцию «Чтение-копирование-обновление », теперь доступную в Linux. В отличие от текущей реализации RCU в Linux, DragonFly реализуется таким образом, что затрагиваются только процессоры, конкурирующие за один и тот же токен, а не все процессоры в компьютере.
DragonFly перешел на многопроцессорный безопасный распределитель блоков, который не требует ни мьютексов, ни блокирующих операций для задач выделения памяти. В конечном итоге он был перенесен в стандартную библиотеку C в пользовательском пространстве, где заменил реализацию malloc FreeBSD.
Начиная с версии 1.8 DragonFly имеет механизм виртуализации, аналогичный Linux в пользовательском режиме., позволяя пользователю запускать другое ядро в пользовательской среде. Виртуальное ядро (vkernel) работает в полностью изолированной среде с эмулированными сетевыми интерфейсами и интерфейсами хранения, что упрощает тестирование подсистем ядра и функций кластеризации.
vkernel имеет два важных отличия от реального ядра: в нем отсутствует множество процедур для имеет дело с низкоуровневым управлением оборудованием и использует функции стандартной библиотеки C (libc) вместо встроенных в ядро реализаций везде, где это возможно. Поскольку как реальное, так и виртуальное ядро скомпилированы из одной и той же базы кода, это фактически означает, что платформенно-зависимые процедуры и повторные реализации функций libc четко разделены в дереве исходных текстов.
vkernel работает поверх оборудования. абстракции, предоставляемые настоящим ядром. К ним относятся таймер на основе kqueue, консоль (сопоставленная с виртуальным терминалом , на котором выполняется vkernel), образ диска и виртуальное ядро Ethernet-устройство (VKE), туннелирующие все пакеты на tap интерфейса хоста.
Стороннее программное обеспечение доступно на DragonFly в виде двоичных пакетов через pkgng
или из собственного Коллекция портов - DPorts.
DragonFly изначально использовал коллекцию FreeBSD Ports в качестве официальной системы управления пакетами, но, начиная с версии 1.4, переключился на NetBSD pkgsrc, которая воспринималась как способ уменьшения объема работы, необходимой для доступности стороннего программного обеспечения. В конце концов, поддержание совместимости с pkgsrc
потребовало больше усилий, чем предполагалось изначально, поэтому в проекте был создан DPorts, наложение поверх коллекции FreeBSD Ports.
Первоначальная реализация Common Address Redundancy Protocol (обычно называемого CARP) была завершена в марте 2007 года. С 2011 года поддержка CARP интегрирована в DragonFly BSD.
Наряду с файловой системой Unix, которая обычно является файловой системой по умолчанию для BSD, DragonFly BSD поддерживает HAMMER и HAMMER2 файловые системы. HAMMER2 - файловая система по умолчанию, начиная с версии 5.2.0.
HAMMER был разработан специально для DragonFly BSD, чтобы предоставить многофункциональный, но лучше спроектированный аналог все более популярного ZFS. HAMMER поддерживает настраиваемую историю файловой системы, снимки, контрольную сумму, дедупликацию данных и другие функции, типичные для файловых систем такого типа.
HAMMER2, преемник файловой системы HAMMER, теперь считается стабильным, используется по умолчанию и находится в центре внимания дальнейшего развития. Планы по его развитию были первоначально обнародованы в 2012 году. В 2017 году Диллон объявил, что следующая версия DragonFly BSD (5.0.0) будет включать полезную, но все еще экспериментальную версию HAMMER2, и описал особенности конструкции. В выпуске после 5.0.0, версия 5.2.0, HAMMER2 стала новой файловой системой по умолчанию.
В 2007 году DragonFly BSD получила новую файловую систему устройства (devfs), которая динамически добавляет и удаляет узлы устройств, позволяет получать доступ к устройствам по путям подключения, распознает диски по серийным номерам и устраняет необходимость в предварительно заполненной иерархии файловой системы / dev
. Он был реализован как проект Google Summer of Code 2009.
DragonFly BSD поддерживает функцию резидентных приложений в стиле Amiga : требуется моментальный снимок пространства виртуальной памяти большой динамически связанной программы после загрузки, позволяющий запускать будущие экземпляры программы намного быстрее, чем это было бы в противном случае. Это заменяет возможность предварительного связывания, над которой работали ранее в истории проекта, поскольку резидентная поддержка намного эффективнее. Большие программы, подобные тем, которые содержатся в KDE Software Compilation со многими разделяемыми библиотеками, получат наибольшую выгоду от этой поддержки.
Как и в случае с FreeBSD и OpenBSD, разработчики DragonFly BSD медленно заменяют предыдущий код функции в стиле C на более современный, ANSI эквиваленты. Подобно другим операционным системам, версия DragonFly из GNU Compiler Collection имеет расширение, называемое Stack-Smashing Protector (ProPolice), включенное по умолчанию, обеспечивая некоторую дополнительную защиту от буфера . Атаки на основе переполнения. По состоянию на 23 июля 2005 г. ядро по умолчанию больше не имеет этой защиты.
Будучи производным от FreeBSD, DragonFly унаследовал простую в использовании интегрированную систему сборки, которая может перестраивать всю базовую систему из источник всего несколькими командами. Разработчики DragonFly используют систему контроля версий Git для управления изменениями исходного кода DragonFly . В отличие от своей родительской FreeBSD, DragonFly имеет как стабильные, так и нестабильные выпуски в одном дереве исходных текстов из-за меньшей базы разработчиков.
Как и другие ядра BSD (и ядра большинства современных операционных систем), DragonFly использует встроенную -в отладчик ядра, чтобы помочь разработчикам найти ошибки ядра. Кроме того, с октября 2004 г. ядро отладки, которое делает отчеты об ошибках более полезными для отслеживания проблем, связанных с ядром, устанавливается по умолчанию за счет относительно небольшого количества дискового пространства. При установке нового ядра из резервной копии предыдущего ядра и его модулей удаляются символы отладки, чтобы дополнительно минимизировать использование дискового пространства.
Операционная система распространяется как Live CD и Live USB (доступен полный вариант X11 ) который загружается в полную систему DragonFly. Он включает базовую систему и полный набор справочных страниц, а также может включать исходный код и полезные пакеты в будущих версиях. Преимущество этого заключается в том, что с одного компакт-диска пользователи могут установить программное обеспечение на компьютер, использовать полный набор инструментов для восстановления поврежденной установки или продемонстрировать возможности системы без ее установки. Ежедневные снимки доступны с главного сайта для тех, кто хочет установить самые последние версии DragonFly без сборки из исходников.
Как и другие бесплатные BSD с открытым исходным кодом, DragonFly распространяется в соответствии с условиями современной версии лицензии BSD.
Версия | Дата | Изменения |
---|---|---|
5.8 | 3 марта 2020 г. | |
5,6 | 17 июня 2019 г. |
|
5.4 | 3 декабря 2018 г. |
|
5.2 | 10 апреля 2018 г. |
|
5.0 | 16 октября 2017 г. |
|
4.8 | 27 марта 2017 г. | |
4.6 | 2 августа 2016 г. |
|
4.4 | 7 декабря 2015 г. | |
4.2 | 29 июня 2015 г. |
|
4.0 | 25 ноября 2014 г. |
|
3.8 | 4 июня 2014 |
|
3.6 | 25 ноября 2013 г. |
|
3.4 | 29 апреля 2013 г. |
|
3.2 | 2 ноября 2012 г. |
|
3.0 | 22 февраля 2012 г. |
|
2.10 | 26 апреля 2011 |
|
2.8 | 30 октября 2010 г. |
|
2,6 | 6 апреля 2010 г. |
|
2.4 | 16 сентября 2009 г. | |
2.2 | 17 февраля 2009 г. | |
2.0 | 20 июля 2008 |
|
1.12 | 26 февраля 2008 г. | |
1.10 | 6 августа 2007 г. |
|
1.8 | 30 января 2007 г. |
|
1.6 | 24 июля 2006 г. |
|
1.4 | 7 января 2006 г. | |
1.2 | 8 апреля 2005 г. | |
1.0 | 12 июля 2004 г. |
|