DragonFly BSD es un sistema operativo tipo Unix, libre y de código abierto, derivado de FreeBSD 4.8. Matthew Dillon , desarrollador de Amiga a finales de los 80 y principios de los 90 y desarrollador de FreeBSD entre 1994 y 2003, comenzó a trabajar en DragonFly BSD en junio de 2003 y lo anunció en las listas de correo de FreeBSD el 16 de julio de 2003. [4]
Dillon inició DragonFly con la creencia de que las técnicas adoptadas para el subprocesamiento y el multiprocesamiento simétrico en FreeBSD 5 [5] darían lugar a problemas de rendimiento y mantenimiento deficientes. Intentó corregir estos problemas previstos dentro del proyecto FreeBSD [6] . Debido a los conflictos con otros desarrolladores de FreeBSD sobre la implementación de sus ideas, [7] su capacidad para cambiar directamente el código base fue finalmente revocada. A pesar de esto, los proyectos DragonFly BSD y FreeBSD siguen trabajando juntos, compartiendo correcciones de errores, actualizaciones de controladores y otras mejoras.
Concebido como la continuación lógica de la serie FreeBSD 4.x, DragonFly se ha desviado significativamente de FreeBSD, implementando subprocesos de núcleo livianos (LWKT), un sistema de paso de mensajes dentro del núcleo y el sistema de archivos HAMMER . [8] Muchos conceptos de diseño fueron influenciados por AmigaOS . [9]
El subsistema de mensajería del núcleo que se está desarrollando es similar a los que se encuentran en micronúcleos como Mach , aunque es menos complejo por diseño. El subsistema de mensajería de DragonFly tiene la capacidad de actuar de manera sincrónica o asincrónica, e intenta utilizar esta capacidad para lograr el mejor rendimiento posible en cualquier situación dada. [10]
Según el desarrollador Matthew Dillon , se están realizando avances para proporcionar capacidades de mensajería de entrada/salida (E/S) de dispositivos y de sistema de archivos virtual (VFS) que permitirán cumplir con el resto de los objetivos del proyecto. La nueva infraestructura permitirá migrar muchas partes del núcleo al espacio de usuario; aquí se depurarán más fácilmente ya que serán programas más pequeños y aislados, en lugar de ser pequeñas partes entrelazadas en un trozo de código más grande. Además, la migración de código de núcleo seleccionado al espacio de usuario tiene el beneficio de hacer que el sistema sea más robusto; si un controlador de espacio de usuario falla, no bloqueará el núcleo. [11]
Las llamadas del sistema se están dividiendo en versiones de usuario y de kernel y se están encapsulando en mensajes. Esto ayudará a reducir el tamaño y la complejidad del kernel al mover variantes de llamadas del sistema estándar a una capa de compatibilidad de usuario y ayudará a mantener la compatibilidad hacia adelante y hacia atrás entre las versiones de DragonFly. Linux y otros códigos de compatibilidad de sistemas operativos tipo Unix se están migrando de manera similar. [9]
Como el soporte para arquitecturas de conjuntos de instrucciones múltiples complica el soporte de multiprocesamiento simétrico (SMP), [7] DragonFly BSD ahora limita su soporte a la plataforma x86-64 . [12] DragonFly originalmente se ejecutaba en la arquitectura x86 , sin embargo, a partir de la versión 4.0 ya no es compatible. Desde la versión 1.10, DragonFly admite subprocesamiento de espacio de usuario 1:1 (un subproceso de kernel por subproceso de espacio de usuario), [13] lo que se considera una solución relativamente simple que también es fácil de mantener. [9] Heredado de FreeBSD, DragonFly también admite subprocesamiento múltiple. [14]
En DragonFly, cada CPU tiene su propio programador de subprocesos. Tras su creación, los subprocesos se asignan a los procesadores y nunca se cambian de forma preventiva de un procesador a otro; solo se migran mediante el paso de un mensaje de interrupción entre procesadores (IPI) entre las CPU implicadas. La programación de subprocesos entre procesadores también se logra mediante el envío de mensajes IPI asíncronos. Una ventaja de esta compartimentación limpia del subsistema de subprocesos es que las cachés integradas de los procesadores en los sistemas multiprocesador simétricos no contienen datos duplicados, lo que permite un mayor rendimiento al dar a cada procesador del sistema la capacidad de utilizar su propia caché para almacenar diferentes cosas en las que trabajar. [9]
El subsistema LWKT se utiliza para dividir el trabajo entre varios subprocesos del núcleo (por ejemplo, en el código de red hay un subproceso por protocolo por procesador), lo que reduce la competencia al eliminar la necesidad de compartir ciertos recursos entre varias tareas del núcleo. [7]
Para ejecutarse de forma segura en máquinas multiprocesador, el acceso a recursos compartidos (como archivos, estructuras de datos) debe ser serializado para que los subprocesos o procesos no intenten modificar el mismo recurso al mismo tiempo. Para evitar que varios subprocesos accedan o modifiquen un recurso compartido simultáneamente, DragonFly emplea secciones críticas y tokens serializadores para evitar el acceso simultáneo. Si bien tanto Linux como FreeBSD 5 emplean modelos mutex de grano fino para lograr un mayor rendimiento en sistemas multiprocesador , DragonFly no lo hace. [7] Hasta hace poco, DragonFly también empleaba spls , pero estos fueron reemplazados por secciones críticas.
Gran parte del núcleo del sistema, incluido el subsistema LWKT , el subsistema de mensajería IPI y el nuevo asignador de memoria del núcleo, no tienen bloqueos, lo que significa que funcionan sin utilizar mutex y cada proceso opera en una sola CPU. Se utilizan secciones críticas para protegerse contra interrupciones locales, individualmente para cada CPU, lo que garantiza que un hilo que se esté ejecutando en ese momento no se interrumpa. [13]
Los tokens serializadores se utilizan para evitar accesos concurrentes desde otras CPU y pueden ser mantenidos simultáneamente por múltiples subprocesos, lo que garantiza que solo uno de esos subprocesos esté en ejecución en un momento dado. Por lo tanto, los subprocesos bloqueados o inactivos no impiden que otros subprocesos accedan al recurso compartido, a diferencia de un subproceso que mantiene un mutex. Entre otras cosas, el uso de tokens serializadores evita muchas de las situaciones que podrían resultar en bloqueos e inversiones de prioridad cuando se utilizan mutexes, además de simplificar enormemente el diseño y la implementación de un procedimiento de varios pasos que requeriría que un recurso se comparta entre varios subprocesos. El código del token serializador está evolucionando hacia algo bastante similar a la función " Lectura-copia-actualización " ahora disponible en Linux. A diferencia de la implementación actual de RCU de Linux, la de DragonFly se está implementando de tal manera que solo se ven afectados los procesadores que compiten por el mismo token en lugar de todos los procesadores de la computadora. [15]
DragonFly cambió a un asignador de bloques seguro para múltiples procesadores , que no requiere ni mutex ni operaciones de bloqueo para tareas de asignación de memoria. [16] Finalmente, se trasladó a la biblioteca C estándar en el espacio de usuario, donde reemplazó la implementación malloc de FreeBSD. [17]
Desde la versión 1.8, DragonFly tiene un mecanismo de virtualización similar al modo usuario de Linux , [18] que permite a un usuario ejecutar otro núcleo en el espacio de usuario. El núcleo virtual ( vkernel ) se ejecuta en un entorno completamente aislado con interfaces de red y almacenamiento emuladas, lo que simplifica la prueba de los subsistemas del núcleo y las funciones de agrupamiento. [9] [11]
El vkernel tiene dos diferencias importantes con el kernel real: carece de muchas rutinas para manejar la administración de hardware de bajo nivel y utiliza funciones de la biblioteca estándar de C (libc) en lugar de implementaciones dentro del kernel siempre que sea posible. Como tanto el kernel real como el virtual se compilan a partir de la misma base de código, esto significa efectivamente que las rutinas dependientes de la plataforma y las reimplementaciones de las funciones libc están claramente separadas en un árbol de código fuente. [19]
El vkernel se ejecuta sobre abstracciones de hardware proporcionadas por el kernel real. Estas incluyen el temporizador basado en kqueue , la consola (asignada a la terminal virtual donde se ejecuta vkernel), la imagen de disco y el dispositivo Ethernet del kernel virtual ( VKE ), que tuneliza todos los paquetes a la interfaz tap del host . [20]
El software de terceros está disponible en DragonFly como paquetes binarios a través de pkgngo desde una colección de puertos nativos : DPorts . [21]
DragonFly originalmente utilizó la colección FreeBSD Ports como su sistema oficial de administración de paquetes , pero a partir de la versión 1.4 cambió al sistema pkgsrc de NetBSD , que fue percibido como una forma de disminuir la cantidad de trabajo necesario para la disponibilidad de software de terceros. [6] [22] Finalmente, mantener la compatibilidad con resultó requerir más esfuerzo del que se anticipó inicialmente, por lo que el proyecto creó DPorts, una superposición sobre la colección FreeBSD Ports . [23] [24]pkgsrc
La implementación inicial del Protocolo de Redundancia de Dirección Común (comúnmente conocido como CARP ) finalizó en marzo de 2007. [25] A partir de 2011, el soporte de CARP está integrado en DragonFly BSD. [26]
Además del sistema de archivos Unix , que suele ser el sistema de archivos predeterminado en los BSD, DragonFly BSD admite los sistemas de archivos HAMMER y HAMMER2 . HAMMER2 es el sistema de archivos predeterminado a partir de la versión 5.2.0.
HAMMER fue desarrollado específicamente para DragonFly BSD para proporcionar un análogo del cada vez más popular ZFS , mejor diseñado y con más funciones . [9] [11] [27] HAMMER admite historial de sistema de archivos configurable, instantáneas , suma de comprobación , deduplicación de datos y otras funciones típicas de los sistemas de archivos de su tipo. [18] [28]
HAMMER2, el sucesor del sistema de archivos HAMMER, ahora se considera estable, se utiliza de forma predeterminada y es el foco de un mayor desarrollo. Los planes para su desarrollo se compartieron inicialmente en 2012. [29] En 2017, Dillon anunció que la próxima versión de DragonFly BSD (5.0.0) incluiría una versión utilizable, aunque todavía experimental, de HAMMER2, y describió las características del diseño. [30] Con el lanzamiento posterior a 5.0.0, la versión 5.2.0, HAMMER2 se convirtió en el nuevo sistema de archivos predeterminado.
En 2007, DragonFly BSD recibió un nuevo sistema de archivos de dispositivos (devfs), que agrega y elimina dinámicamente nodos de dispositivos, permite acceder a los dispositivos mediante rutas de conexión, reconoce unidades por números de serie y elimina la necesidad de una jerarquía de sistemas de archivos precargada /dev. Se implementó como un proyecto de Google Summer of Code 2009. [31]
DragonFly BSD es compatible con la característica de las aplicaciones residentes de estilo Amiga : toma una instantánea del espacio de memoria virtual de un programa grande y vinculado dinámicamente después de la carga, lo que permite que las instancias futuras del programa se inicien mucho más rápido de lo que lo hubieran hecho de otra manera. Esto reemplaza la capacidad de preenlace en la que se estaba trabajando anteriormente en la historia del proyecto, ya que el soporte residente es mucho más eficiente. Los programas grandes como los que se encuentran en KDE Software Compilation con muchas bibliotecas compartidas se beneficiarán más de este soporte. [32]
Al igual que con FreeBSD y OpenBSD , los desarrolladores de DragonFly BSD están reemplazando lentamente el código C de estilo prototipo pre-funcional con equivalentes ANSI más modernos . Al igual que otros sistemas operativos, la versión de DragonFly de la Colección de compiladores GNU tiene una mejora llamada Stack-Smashing Protector (ProPolice) habilitada por defecto, que proporciona cierta protección adicional contra ataques basados en desbordamiento de búfer . A partir del 23 de julio de 2005 , el núcleo ya no se construye con esta protección por defecto. [32][actualizar]
Al ser un derivado de FreeBSD, DragonFly ha heredado un sistema de compilación integrado fácil de usar que puede reconstruir todo el sistema base desde el código fuente con solo unos pocos comandos. Los desarrolladores de DragonFly usan el sistema de control de versiones Git para administrar los cambios en el código fuente de DragonFly . A diferencia de su padre FreeBSD, DragonFly tiene versiones estables e inestables en un solo árbol de código fuente, debido a una base de desarrolladores más pequeña. [7]
Al igual que los otros núcleos BSD (y los de la mayoría de los sistemas operativos modernos), DragonFly emplea un depurador de núcleo integrado para ayudar a los desarrolladores a encontrar errores en el núcleo. Además, desde octubre de 2004 [actualizar], se instala de forma predeterminada un núcleo de depuración, que hace que los informes de errores sean más útiles para rastrear problemas relacionados con el núcleo, a expensas de una cantidad relativamente pequeña de espacio en disco. Cuando se instala un nuevo núcleo, la copia de seguridad del núcleo anterior y sus módulos se despojan de sus símbolos de depuración para minimizar aún más el uso de espacio en disco.
El sistema operativo se distribuye como un Live CD y un Live USB que arranca en un sistema DragonFly completo. [18] [31] Incluye el sistema base y un conjunto completo de páginas de manual, y puede incluir código fuente y paquetes útiles en futuras versiones. La ventaja de esto es que con un solo CD los usuarios pueden instalar el software en una computadora, usar un conjunto completo de herramientas para reparar una instalación dañada o demostrar las capacidades del sistema sin instalarlo. Las instantáneas diarias están disponibles en el sitio maestro para aquellos que quieran instalar las versiones más recientes de DragonFly sin compilar desde la fuente.
Al igual que otros BSD gratuitos y de código abierto, DragonFly se distribuye bajo los términos de la versión moderna de la licencia BSD .
HAMMER parece ser un sistema de archivos BSD muy interesante. Aunque no es tan rápido como el sistema de archivos ZFS de BSD, también es un sistema de archivos original del proyecto DragonFlyBSD en lugar de ser un puerto de OpenSolaris. HAMMER no solo es generalmente más rápido que el sistema de archivos UFS común, sino que también tiene un conjunto de características mucho mayor.
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}