DragonFly BSD

DragonFly BSD; sistema operativo
Sviluppatore	Matt Dillon
Famiglia	BSD
Release iniziale	1.0 (12 luglio 2004; 19 anni fa)
Release corrente	6.4.0 (30 dicembre 2022)
Tipo di kernel	Kernel ibrido
Piattaforme supportate	x86-64
Gestore dei pacchetti	DPorts, pkgng
Tipo licenza	Software libero
Licenza	BSD
Stadio di sviluppo	in produzione
Sito web	www.dragonflybsd.org/

Dragonfly BSD è un sistema operativo Unix-like per macchine multiprocessori derivato dalla versione 4.8 di FreeBSD. Al momento supporta solo l'architettura x86-64. L'architettura 32bit è stata dismessa il 15 novembre 2014.

Storia modifica

Il progetto nacque dall'idea di Matthew Dillon, uno sviluppatore Amiga, perché non era soddisfatto dal metodo con cui FreeBSD gestiva i sistemi multiprocessori, attraverso SMPng (derivato dal codice di BSD/OS 5).

Lo sviluppo di Dragonfly BSD iniziò nel giugno del 2003 e venne annunciato nel mese di luglio dello stesso anno.^[2] La base di codice è stata presa dal rilascio 4.8 di FreeBSD, che ha offerto le prestazioni migliori e le caratteristiche più complete. Si è scelto di utilizzare un'architettura che tenesse conto della differente velocità di accesso alle memorie presenti in un sistema, quali cache e RAM (Random Access Memory), che è di fondamentale importanza nella realizzazione di sistemi multiprocessore.

Questa architettura è denominata NUMA (Non Uniform Memory Access) e consente l'utilizzo di un sistema con un elevato numero di vie velocizzando il transito dei dati tra CPU e memoria. La filosofia di Dragonfly è la suddivisione esplicita del lavoro tra i processori, ovvero significa che un processo non sarà mai trasferito su un'altra CPU permettendo quindi di utilizzare al meglio i dati contenuti nella cache e senza dover effettuare il lock.

Dragonfly BSD è sviluppato da molti programmatori in tutto il mondo. Non c'è processo di qualificazione; chiunque può presentare il suo codice, documentazione o disegni per uso nel progetto.

Caratteristiche modifica

Il kernel modifica

Dragonfly BSD è il primo sistema operativo di tipo BSD ad adottare un'architettura a kernel ibrido, ovvero il kernel condivide i concetti e i meccanismi d'architettura sia dei kernel monolitici che delle tipologie micro. Il modello LWKT (Light Weight Kernel Threading) funziona associando ogni processo ad un thread. Ogni CPU ha il proprio scheduler LWKT. In questo modo i thread sono assegnati ad una specifica CPU permettendo così la gestione senza la necessità di utilizzare un lock MP.

Inoltre, grazie alla protezione di memoria, un thread non può essere spostato su un'altra CPU da un thread a priorità maggiore e le applicazioni non interferiranno mai tra di loro.
La gestione dei thread utente viene effettuata da uno scheduler dedicato, chiamato Userland e la sua esecuzione è regolata, anche nell'eventualità di un'interruzione, dai dati contenuti nella cache.

La comunicazione dei sottosistemi modifica

La comunicazione attuata nella maggior parte dei sottosistemi comunicativi di Dragonfly avviene attraverso l'Inter-processor Interrupt. Questo sistema è utilizzato per suddividere thread e memoria libera sulle altre CPU. I messaggi generati da queste ultime sono costituiti da una chiamata avente un puntatore a funzione e i dati relativi che la CPU destinataria eseguirà in modo asincrono. In questo modo si avranno grandi vantaggi dal punto di vista della performance, in quanto la CPU chiamante non attenderà l'esecuzione della CPU destinataria. La ricezione di un messaggio IP da parte di una CPU prevede la sospensione del thread attualmente in esecuzione rendendolo non bloccabile.

La gestione dei thread nel kernel modifica

La gestione dei thread nel kernel avviene attraverso lo slab allocator, un sottosistema che permette l'accesso a porzioni di codice critico senza negare alle altre CPU l'utilizzo del restante kernel. In altre parole, quando una CPU ha bisogno di utilizzare una parte del kernel, blocca con un lock globale l'accesso al kernel per il tempo necessario ad escludere quella determinata sezione dall'esecuzione da parte delle altra CPU.
Questo processo prevede che lo slab allocator di ogni CPU abbia a che fare con 128k di kernel che poi verranno distribuiti e suddivisi in aree più piccole in base alla richiesta dei thread.