DragonFly BSD - DragonFly BSD
 | |
 DragonFly BSD 5.2.0 cu mediu desktop Lumina
| |
| Dezvoltator | Matthew Dillon |
|---|---|
| Familia OS | Unix-like |
| Starea de lucru | Actual |
| Modelul sursă | Sursa deschisa |
| Eliberarea inițială | 1.0 / 12 iulie 2004 |
| Ultima lansare | 6.0.1 / 13 octombrie 2021 |
| Repertoriu | |
| Disponibil in | Engleză |
| Manager de pachete | pachet |
| Platforme | x86-64 |
| Tipul de nucleu | Hibrid |
| Userland | BSD |
Interfață de utilizator implicită |
Unix shell |
| Licență | BSD |
| Site oficial | www |
DragonFly BSD este un sistem de operare gratuit și open-source Unix asemănător cu cel de la FreeBSD 4.8. Matthew Dillon , dezvoltator Amiga la sfârșitul anilor 1980 și începutul anilor 1990 și dezvoltator FreeBSD între 1994 și 2003, a început să lucreze la DragonFly BSD în iunie 2003 și l-a anunțat pe listele de distribuție FreeBSD pe 16 iulie 2003.
Dillon a început DragonFly în convingerea că tehnicile adoptate pentru filetare și multiprocesare simetrică în FreeBSD 5 ar duce la probleme de performanță și întreținere. El a căutat să corecteze aceste probleme anticipate în cadrul proiectului FreeBSD. Datorită conflictelor cu alți dezvoltatori FreeBSD privind implementarea ideilor sale, abilitatea sa de a schimba direct baza de cod a fost în cele din urmă revocată. În ciuda acestui fapt, proiectele DragonFly BSD și FreeBSD încă funcționează împreună, partajând remedieri de erori, actualizări ale driverelor și alte îmbunătățiri.
Conceput ca continuarea logică a seriei FreeBSD 4.x, DragonFly a diferit semnificativ de FreeBSD, implementând fire de kernel ușoare (LWKT), un sistem de transmitere a mesajelor în kernel și sistemul de fișiere HAMMER . Multe concepte de design au fost influențate de AmigaOS .
Proiectarea sistemului
Nucleu
Nucleu Subsistemul de mesaje în curs de dezvoltare este similar cu cele găsite în micronucleu , cum ar fi Mach , deși este mai puțin complex prin design. Cu toate acestea, DragonFly folosește un sistem de nucleu monolitic. Subsistemul de mesagerie DragonFly are capacitatea de a acționa fie într-o manieră sincronă, fie asincronă și încearcă să utilizeze această capacitate pentru a obține cele mai bune performanțe posibile în orice situație dată.
Potrivit dezvoltatorului Matthew Dillon , se fac progrese în furnizarea atât a capacităților de mesagerie de intrare / ieșire a dispozitivului (I / O), cât și a sistemului de fișiere virtuale (VFS) care vor permite îndeplinirea celorlalte obiective ale proiectului. Noua infrastructură va permite ca multe părți ale nucleului să fie migrate în spațiul utilizatorilor; aici vor fi depanate mai ușor, deoarece vor fi programe mai mici, izolate, în loc să fie părți mici legate într-o bucată mai mare de cod. În plus, migrarea codului de nucleu selectat în spațiul utilizatorilor are avantajul de a face sistemul mai robust; dacă un driver de spațiu utilizator se blochează, acesta nu va bloca nucleul.
Apelurile de sistem sunt împărțite în versiunile userland și kernel și sunt încapsulate în mesaje. Acest lucru va ajuta la reducerea dimensiunii și complexității nucleului prin mutarea variantelor de apeluri de sistem standard într-un strat de compatibilitate a țării utilizatorilor și va ajuta la menținerea compatibilității înainte și înapoi între versiunile DragonFly. Linux și alte coduri de compatibilitate cu sistemul de operare similar Unix sunt migrate în mod similar.
Filetat
Deoarece suportul pentru arhitecturi de seturi de instrucțiuni multiple complică suportul multiprocesării simetrice (SMP), DragonFly BSD își limitează acum suportul la platforma x86-64 . DragonFly a funcționat inițial pe arhitectura x86 , totuși de la versiunea 4.0 nu mai este acceptat. Începând cu versiunea 1.10, DragonFly acceptă threading 1: 1 userland (un fir de kernel per thread userland), care este considerat o soluție relativ simplă, care este, de asemenea, ușor de întreținut. Moștenit de la FreeBSD, DragonFly acceptă și multi-threading.
În DragonFly, fiecare procesor are propriul programator de fire. La creare, firele sunt atribuite procesoarelor și nu sunt niciodată comutate preventiv de la un procesor la altul; acestea sunt migrate numai prin trecerea unui mesaj de întrerupere inter-procesor (IPI) între procesoarele implicate. Programarea firelor inter-procesor se realizează și prin trimiterea de mesaje IPI asincrone. Un avantaj al acestei compartimentări curate a subsistemului de filetare este că cache - urile de la bord ale procesoarelor din sistemele multiprocesor simetrice nu conțin date duplicate, permițând performanțe mai mari oferind fiecărui procesor din sistem capacitatea de a utiliza propria cache pentru a stoca diferite lucruri la care să lucrezi.
LWKT Subsistemul este angajat la locul de muncă partiție între mai multe fire de nucleu (de exemplu , în codul de rețea există un fir per protocol per procesor), reducerea concurenței prin eliminarea necesității de a împărtăși anumite resurse între diferite sarcini de kernel.
Pentru a rula în siguranță pe mașini multiprocesor, accesul la resursele partajate (cum ar fi fișiere, structuri de date) trebuie serializat, astfel încât firele sau procesele să nu încerce să modifice aceeași resursă în același timp. Pentru a împiedica mai multe fire de acces sau de a modifica simultan o resursă partajată, DragonFly folosește secțiuni critice și serializează jetoane pentru a preveni accesul simultan. În timp ce atât Linux, cât și FreeBSD 5 folosesc modele mutex cu granulație fină pentru a obține performanțe mai mari pe sistemele multiprocesor , DragonFly nu. Până de curând, DragonFly folosea și spls , dar acestea au fost înlocuite cu secțiuni critice.
O mare parte din nucleul sistemului, inclusiv subsistemul LWKT , subsistemul de mesagerie IPI și noul alocator de memorie kernel, sunt fără blocare, ceea ce înseamnă că funcționează fără a utiliza mutexe, fiecare proces funcționând pe un singur procesor. Secțiunile critice sunt folosite pentru a proteja împotriva întreruperilor locale, individual pentru fiecare CPU, garantând că un fir executat în prezent nu va fi împiedicat.
Jetoanele de serializare sunt utilizate pentru a preveni accesele simultane de la alte procesoare și pot fi ținute simultan de mai multe fire de execuție, asigurându-se că doar unul dintre acele fire de execuție se execută la un moment dat. Firele blocate sau adormite, prin urmare, nu împiedică alte fire să acceseze resursa partajată, spre deosebire de un fir care ține un mutex. Printre altele, utilizarea jetoanelor de serializare previne multe dintre situațiile care ar putea duce la blocaje și inversiuni de prioritate atunci când se utilizează mutexuri, precum și simplificarea considerabilă a proiectării și implementării unei proceduri în mai mulți pași care ar necesita o resursă care să fie partajată între fire multiple. Codul jetonului de serializare evoluează spre ceva destul de similar cu caracteristica „ Citire-copiere-actualizare ” disponibilă acum în Linux. Spre deosebire de implementarea actuală a RCU Linux, DragonFly's este implementat astfel încât numai procesoarele care concurează pentru același token sunt afectate, mai degrabă decât toți procesoarele din computer.
DragonFly a trecut la repartitorul de plăci cu siguranță multiprocesor , care nu necesită nici mutexuri, nici operațiuni de blocare pentru sarcinile de atribuire a memoriei. În cele din urmă a fost portat în biblioteca standard C din țara utilizatorilor, unde a înlocuit implementarea malloc a FreeBSD.
Kernel virtual
De la lansarea 1.8 DragonFly are un mecanism de virtualizare similar cu Linux în modul utilizator , permițând utilizatorului să ruleze un alt kernel în țara utilizatorilor. Kernelul virtual ( vkernel ) este rulat într-un mediu complet izolat cu interfețe de rețea și stocare emulate, simplificând astfel testarea subsistemelor kernelului și caracteristicile de clusterizare.
Vkernel-ul are două diferențe importante față de nucleul real: îi lipsesc multe rutine pentru gestionarea hardware-ului de nivel scăzut și folosește funcții de bibliotecă standard C (libc) în locul implementărilor in-kernel ori de câte ori este posibil. Deoarece atât nucleul real, cât și cel virtual sunt compilate din aceeași bază de cod, aceasta înseamnă în mod eficient că rutinele dependente de platformă și reimplementările funcțiilor libc sunt clar separate într-un arbore sursă.
Vkernel rulează pe partea superioară a abstractizărilor hardware furnizate de nucleul real. Acestea includ cronometrul bazat pe kqueue , consola (mapată la terminalul virtual unde este executat vkernel), imaginea discului și dispozitivul Ethernet al kernelului virtual ( VKE ), tunelând toate pachetele către interfața de atingere a gazdei .
Gestionarea pachetelor
Software-ul terț este disponibil pe DragonFly ca pachete binare prin pkgngsau dintr-o colecție de porturi native - DPorts .
DragonFly a folosit inițial colecția FreeBSD Ports ca sistem oficial de gestionare a pachetelor , dar începând cu versiunea 1.4 a trecut la sistemul pkgsrc al NetBSD , care a fost perceput ca o modalitate de a reduce cantitatea de muncă necesară pentru disponibilitatea software-ului terților. În cele din urmă, menținerea compatibilității cu pkgsrcs-a dovedit a necesita mai mult efort decât s-a anticipat inițial, astfel încât proiectul a creat DPorts, o suprapunere peste colecția FreeBSD Ports .
Suport CARP
Implementarea inițială a Protocolului comun de redundanță a adresei (denumit în mod obișnuit CARP ) a fost finalizată în martie 2007. Începând din 2011, suportul CARP este integrat în DragonFly BSD.
Sisteme de fișiere HAMMER
Alături de sistemul de fișiere Unix , care este de obicei sistemul de fișiere implicit pe BSD-uri, DragonFly BSD acceptă sistemele de fișiere HAMMER și HAMMER2 . HAMMER2 este sistemul de fișiere implicit începând cu versiunea 5.2.0.
HAMMER a fost dezvoltat special pentru DragonFly BSD pentru a oferi un analog bogat în funcții, dar mai bine conceput al ZFS din ce în ce mai popular . HAMMER acceptă istoricul sistemelor de fișiere configurabile, instantanee , sumă de verificare , deduplicarea datelor și alte caracteristici tipice pentru sistemele de fișiere de acest gen.
HAMMER2, succesorul sistemului de fișiere HAMMER, este acum considerat stabil, utilizat în mod implicit și este centrul dezvoltării ulterioare. Planurile pentru dezvoltarea sa au fost inițial partajate în 2012. În 2017, Dillon a anunțat că următoarea versiune DragonFly BSD (5.0.0) va include o versiune utilizabilă, deși încă experimentală, a HAMMER2 și a descris caracteristicile designului. Odată cu lansarea după 5.0.0, versiunea 5.2.0, HAMMER2 a devenit noul sistem de fișiere implicit.
devfs
În 2007, DragonFly BSD a primit un nou sistem de fișiere de dispozitiv (devfs), care adaugă și elimină dinamic nodurile dispozitivului, permite accesarea dispozitivelor prin căile de conectare, recunoaște unitățile după numere de serie și elimină necesitatea /devierarhizării sistemului de fișiere pre-populat . A fost implementat ca un proiect Google Summer of Code 2009.
Instantanee ale aplicației
DragonFly BSD acceptă caracteristica aplicațiilor rezidente în stilul Amiga : realizează un instantaneu al spațiului de memorie virtual al unui program mare, legat dinamic, după încărcare, permițând instanțelor viitoare ale programului să înceapă mult mai repede decât ar fi avut altfel. Acest lucru înlocuiește capacitatea de prelinking la care se lucra mai devreme în istoria proiectului, deoarece asistența rezidenților este mult mai eficientă. Programele mari precum cele găsite în Compilația software KDE cu multe biblioteci partajate vor beneficia cel mai mult de acest suport.
Dezvoltare și distribuție
La fel ca în cazul FreeBSD și OpenBSD , dezvoltatorii DragonFly BSD înlocuiesc încet codul C- stil prototip funcțional cu echivalente ANSI mai moderne . Similar cu alte sisteme de operare, versiunea DragonFly a GNU Compiler Collection are o îmbunătățire numită Stack-Smashing Protector (ProPolice) activată în mod implicit, oferind o protecție suplimentară împotriva atacurilor bazate pe depășirea bufferului . Începând cu 23 iulie 2005, nucleul nu mai este construit în mod implicit cu această protecție.
Fiind un derivat al FreeBSD, DragonFly a moștenit un sistem de construcție integrat ușor de utilizat, care poate reconstrui întregul sistem de bază din sursă cu doar câteva comenzi. Dezvoltatorii DragonFly folosesc sistemul de control al versiunilor Git pentru a gestiona modificările aduse codului sursă DragonFly . Spre deosebire de FreeBSD-ul său părinte, DragonFly are atât versiuni stabile, cât și instabile într-un singur arbore sursă, datorită unei baze de dezvoltatori mai mici.
La fel ca celelalte nuclee BSD (și cele ale majorității sistemelor de operare moderne), DragonFly folosește un debugger încorporat pentru a ajuta dezvoltatorii să găsească erori ale nucleului. Mai mult, din octombrie 2004, un nucleu de depanare, care face ca rapoartele de erori să fie mai utile pentru depistarea problemelor legate de nucleu, este instalat în mod implicit, în detrimentul unei cantități relativ mici de spațiu pe disc. Când este instalat un nou nucleu, copia de rezervă a nucleului anterior și a modulelor sale sunt eliminate de simbolurile lor de depanare pentru a minimiza și mai mult utilizarea spațiului pe disc.
Medii de distribuție
Sistemul de operare este distribuit sub forma unui CD live și a unui USB Live ( disponibilă întreaga aromă X11 ) care pornește într-un sistem DragonFly complet. Acesta include sistemul de bază și un set complet de pagini de manual și poate include cod sursă și pachete utile în versiunile viitoare. Avantajul acestui lucru este că, cu un singur CD, utilizatorii pot instala software-ul pe un computer, pot folosi un set complet de instrumente pentru a repara o instalare deteriorată sau pot demonstra capacitățile sistemului fără a-l instala. Instantaneele zilnice sunt disponibile de pe site-ul principal pentru cei care doresc să instaleze cele mai recente versiuni ale DragonFly fără a construi din sursă.
La fel ca celelalte BSD-uri gratuite și open-source, DragonFly este distribuit în condițiile versiunii moderne a licenței BSD .
Istoricul lansărilor
| Versiune | Data | Schimbări |
|---|---|---|
| 6.0 | 10 mai 2021 |
|
| 5.8 | 3 martie 2020 | |
| 5.6 | 17 iunie 2019 |
|
| 5.4 | 3 decembrie 2018 |
|
| 5.2 | 10 aprilie 2018 |
|
| 5.0 | 16 octombrie 2017 |
|
| 4.8 | 27 martie 2017 |
|
| 4.6 | 2 august 2016 |
|
| 4.4 | 7 decembrie 2015 | |
| 4.2 | 29 iunie 2015 |
|
| 4.0 | 25 noiembrie 2014 |
|
| 3.8 | 4 iunie 2014 |
|
| 3.6 | 25 noiembrie 2013 |
|
| 3.4 | 29 aprilie 2013 |
|
| 3.2 | 2 noiembrie 2012 |
|
| 3.0 | 22 februarie 2012 |
|
| 2.10 | 26 aprilie 2011 |
|
| 2.8 | 30 octombrie 2010 |
|
| 2.6 | 6 aprilie 2010 |
|
| 2.4 | 16 septembrie 2009 | |
| 2.2 | 17 februarie 2009 | |
| 2.0 | 20 iulie 2008 |
|
| 1.12 | 26 februarie 2008 | |
| 1.10 | 6 august 2007 |
|
| 1.8 | 30 ianuarie 2007 |
|
| 1.6 | 24 iulie 2006 |
|
| 1.4 | 7 ianuarie 2006 | |
| 1.2 | 8 aprilie 2005 | |
| 1.0 | 12 iulie 2004 |
|
Vezi si
- Compararea sistemelor de operare BSD
- Compararea sistemelor de operare open-source
- Comparația nucleelor sistemului de operare
