Sisteme de operare micronucleare. Sistem de operare Microkernel Funcții Microkernel

Curs 4. Arhitectura microkernel-ului OS

1. Conceptul de arhitectură micronucleară.

2. Avantajele și dezavantajele arhitecturii microkernel

3. Compatibilitate cu sistemul de operare

1. Concept arhitectura micronucleara

Arhitectura microkernel este o alternativă la modul clasic de a construi un sistem de operare. Arhitectura clasică în acest caz se referă la organizarea structurală a sistemului de operare discutată mai sus, în conformitate cu care toate funcțiile de bază ale sistemului de operare care alcătuiesc nucleul cu mai multe straturi rulează în modul privilegiat. În același timp, unele funcții auxiliare ale sistemului de operare sunt realizate sub formă de aplicații și sunt executate în modul utilizator împreună cu programele utilizator obișnuite (devenind utilități de sistem sau programe de procesare). Fiecare aplicație în modul utilizator rulează în propriul spațiu de adrese și este astfel protejată de orice interferență a altor aplicații. Codul kernel care se execută în modul privilegiat are acces la zonele de memorie ale tuturor aplicațiilor, dar este el însuși complet protejat de acestea. Aplicațiile accesează nucleul cu solicitări de a executa funcțiile sistemului.

Esența arhitecturii micronucleare este următoarea. În modul privilegiat, doar o parte foarte mică a sistemului de operare, apelată microkernel(Fig. 1). Microkernel-ul este protejat de restul sistemului de operare și al aplicațiilor. Microkernel-ul include de obicei module dependente de mașină, precum și module care îndeplinesc funcții de bază (dar nu toate!) Kernel-ului pentru gestionarea proceselor, gestionarea întreruperilor, gestionarea memorie virtuala, redirecționarea mesajelor și gestionarea dispozitivelor I/O asociate cu încărcarea sau citirea registrelor dispozitivului. Setul de funcții al unui microkernel corespunde de obicei cu funcțiile stratului de mecanisme de bază ale unui nucleu obișnuit. Astfel de funcții ale sistemului de operare sunt dificil, dacă nu imposibil, de realizat în spațiul utilizatorului.

Orez. unu. Portarea cea mai mare parte a funcțiilor kernelului în spațiul utilizatorului

Toate celelalte funcții ale nucleului de nivel superior sunt documentate în; forma aplicațiilor care rulează în modul utilizator. Nu există o decizie clară cu privire la care dintre funcțiile sistemului ar trebui lăsată în modul privilegiat și care ar trebui mutată în modul utilizator. În general, mulți dintre managerii de resurse care sunt parte integrantă a nucleului obișnuit - sistemul de fișiere, memoria virtuală și subsistemele de gestionare a proceselor, managerul de securitate și așa mai departe - devin module „periferice” în modul utilizator.

Managerii de resurse care rulează în modul utilizator sunt fundamental diferiți de utilitățile tradiționale ale sistemului de operare și de programele de procesare, deși într-o arhitectură microkernel toate aceste componente software sunt, de asemenea, ambalate ca aplicații. Utilitarele și programele de procesare sunt apelate în primul rând de utilizatori. Situațiile în care o aplicație trebuie să execute o funcție (procedură) a unei alte aplicații sunt extrem de rare. Prin urmare, sistemelor de operare cu arhitectură clasică le lipsește un mecanism prin care o aplicație poate apela funcțiile alteia.

O situație complet diferită apare atunci când o parte a sistemului de operare este oficializată sub forma unei aplicații. Prin definiție, scopul principal al unei astfel de aplicații este acela de a servi solicitări de la alte aplicații, cum ar fi crearea unui proces, alocarea memoriei, verificarea drepturilor de acces la o resursă etc. De aceea, managerii de resurse plasați în modul utilizator sunt numiți. servere OS, adică module al căror scop principal este de a deservi cererile de la aplicații locale și alte module OS. Este evident că pentru a implementa o arhitectură microkernel conditie necesara este prezenţa în sistemul de operare a unui convenabil şi mod eficient apelarea procedurilor unui proces de la altul. Suportul pentru un astfel de mecanism este una dintre sarcinile principale ale microkernel-ului.

Schematic, mecanismul de accesare a funcțiilor OS, concepute ca servere, este următorul (Fig. 2). Clientul, care poate fi fie un program de aplicație, fie o altă componentă a sistemului de operare, solicită executarea unei anumite funcții de la serverul corespunzător, trimițându-i un mesaj. Mesageria directă între aplicații nu este posibilă deoarece spațiile lor de adrese sunt izolate unele de altele. Un microkernel care rulează în modul privilegiat are acces la spațiile de adrese ale fiecăreia dintre aceste aplicații și, prin urmare, poate acționa ca intermediar. Microkernel-ul trimite mai întâi un mesaj care conține numele și parametrii procedurii apelate. serverul potrivit, apoi serverul efectuează operația solicitată, după care nucleul returnează rezultatele clientului cu alt mesaj. Astfel, funcționarea unui sistem de operare microkernel corespunde binecunoscutului model client-server, în care rolul vehiculelor este îndeplinit de microkernel.

https://pandia.ru/text/78/240/images/image003_9.jpg" width="520" height="224 src=">

Orez. 3. Schimbarea modurilor la efectuarea unui apel de sistem

Severitatea acestui neajuns este bine ilustrată de istoria dezvoltării Windows NT. În versiunile 3.1 și 3.5, managerul de ferestre, biblioteca grafică și driverele de nivel înalt dispozitive grafice făceau parte din serverul în modul utilizator, iar funcțiile acestor module au fost apelate în conformitate cu schema microkernel-ului. Cu toate acestea, foarte curând Dezvoltatorii Windows NT a realizat că acest mecanism de accesare a funcțiilor GUI utilizate în mod obișnuit a încetinit semnificativ aplicațiile și a lăsat sistemul de operare vulnerabil la concurență intensă. Ca urmare, au fost aduse modificări semnificative versiunii Windows NT 4.0 - toate modulele enumerate mai sus au fost transferate în nucleu, ceea ce a îndepărtat acest sistem de operare de arhitectura ideală a microkernelului, dar i-a crescut dramatic performanța.

Acest exemplu ilustrează principala problemă cu care se confruntă dezvoltatorii de sisteme de operare care decid să adopte o abordare microkernel - ce să includă în microkernel și ce să introducă în spațiul utilizatorului. În cazul ideal, microkernel-ul poate consta doar din facilități de transmitere a mesajelor, facilități pentru interacțiunea cu hardware-ul, inclusiv facilități pentru accesarea mecanismelor de protecție privilegiate. Cu toate acestea, mulți dezvoltatori nu respectă întotdeauna cu strictețe principiul minimizării funcțiilor kernelului, sacrificând adesea acest lucru de dragul performanței. Drept urmare, implementările OS formează un anumit spectru, pe de o parte din care există sisteme cu cel mai mic microkernel posibil, iar pe de altă parte - sisteme precum Windows NT, în care microkernel-ul îndeplinește o cantitate destul de mare de funcții.

3. Compatibilitate cu sistemul de operare

În timp ce multe caracteristici arhitecturale ale sistemelor de operare sunt de interes direct doar pentru programatorii de sistem, conceptul mai multe medii de aplicații este direct legată de nevoile utilizatorilor finali – capacitatea sistemului de operare de a rula aplicații scrise pentru alte sisteme de operare. Această proprietate a sistemului de operare este numită compatibilitate.

Compatibilitate binară și sursă

Este necesar să se facă distincția între compatibilitatea la nivel binar și compatibilitatea la nivel de cod sursă. Aplicațiile sunt de obicei stocate în sistemul de operare ca fișiere executabile care conțin imagini binare de cod și date. Compatibilitatea binară se realizează atunci când puteți lua un program executabil și îl puteți rula pe alt sistem de operare.

Compatibilitatea la nivel de sursă necesită ca un compilator adecvat să fie inclus în software-ul computerului pe care este destinat să ruleze aceasta aplicație, precum și compatibilitatea la nivel de biblioteci și apeluri de sistem. Acest lucru necesită recompilarea surselor existente într-un nou modul executabil.

Compatibilitatea la nivel de sursă este importantă în principal pentru dezvoltatorii de aplicații care au întotdeauna aceste surse la dispoziție. Dar pentru utilizatorii finali, doar compatibilitatea binară este de importanță practică, deoarece doar în acest caz pot folosi același produs comercial, livrat ca cod binar executabil, în medii de operare diferite și pe mașini diferite. Pentru un utilizator care a cumpărat un pachet (de exemplu, Lotus 1-2-3) pentru MS-DOS, este important să poată rula acest pachet care îi place fără nicio modificare a acestuia. mașină nouă rulează, de exemplu, Windows NT.

Dacă un nou sistem de operare este compatibil binar sau compatibil cu codul sursă cu sistemele de operare existente depinde de mulți factori. Cea mai importantă dintre ele este arhitectura procesorului pe care rulează noul sistem de operare. Dacă procesorul folosește același set de instrucțiuni (poate cu unele completări) și același interval de adrese, atunci compatibilitatea binară poate fi realizată destul de ușor. Pentru a face acest lucru, este suficient să respectați următoarele condiții:

* apelurile la funcțiile API pe care le conține aplicația trebuie să fie suportate de acest sistem de operare;

* structura internă a fișierului executabil al aplicației trebuie să se potrivească cu structura fișierelor executabile ale sistemului de operare.

Este mult mai dificil să se obțină compatibilitate binară pentru sistemele de operare concepute să ruleze pe procesoare care au arhitecturi diferite. Pe lângă respectarea condițiilor de mai sus, este necesar să se organizeze emulare cod binar.

De exemplu, să presupunem că doriți să rulați un program DOS pentru un computer compatibil IBM PC pe un computer Macintosh. Computerul Macintosh se bazează pe procesorul Motorola 680x0, în timp ce PC-ul IBM se bazează pe procesor Intel 80x86. Procesorul Motorola are o arhitectură (sistem de instrucțiuni, compoziția registrului etc.) care este diferită de arhitectura procesorului Intel, deci nu înțelege codul binar al programului DOS care conține instrucțiunile acestui procesor. Pentru ca computerul Macintosh să poată interpreta instrucțiunile mașinii pe care nu le înțelege inițial, trebuie să fie instalat pe el un software special - un emulator.

Emulatorul trebuie să selecteze secvenţial fiecare instrucţiune binară a procesorului Intel, în mod programatic decodați-l pentru a determina ce face și apoi executați subrutina echivalentă scrisă în instrucțiunile procesorului Motorola. Deoarece, în plus, procesorul Motorola nu are exact aceleași registre, steaguri și unitate internă aritmetic-logică ca la Intel, trebuie să simuleze (emuleze) toate aceste elemente folosind propriile registre sau memorie. Starea registrelor și steagurilor emulate după executarea fiecărei comenzi trebuie să fie exact aceeași ca într-un procesor Intel real.

Aceasta este o operație simplă, dar foarte lentă, deoarece o instrucțiune a procesorului Intel este executată mult mai rapid decât secvența de instrucțiuni a procesorului Motorola care o emulează.

Traducerea bibliotecilor

Calea de ieșire în astfel de cazuri este să folosiți așa-numitul medii software aplicate. Una dintre componentele care formează mediul de programare a aplicațiilor este un set de funcții de interfață de programare a aplicațiilor API care sistem de operare oferă aplicațiilor lor. Pentru a reduce timpul de execuție a programelor altora, mediile de aplicații imită apelurile la funcțiile de bibliotecă.

Eficacitatea acestei abordări se datorează faptului că majoritatea programelor de astăzi rulează sub GUI (interfețe grafice de utilizator) precum Windows, Mac sau UNIX Motif, aplicațiile petrecându-și majoritatea timpului făcând unele acțiuni bine previzibile. Ei efectuează în mod continuu apeluri către bibliotecile GUI pentru manipularea ferestrelor și alte activități legate de GUI. Astăzi, în programele tipice, 60-80% din timp este petrecut executând funcții GUI și alte apeluri de bibliotecă OS. Această proprietate a aplicațiilor este cea care permite mediilor de aplicații să compenseze timpul mare petrecut cu emularea comandă cu comandă a unui program. Un mediu de aplicație software conceput cu grijă conține biblioteci care imită bibliotecile GUI interne, dar scrise în cod nativ. Astfel, se realizează o accelerare semnificativă a execuției programelor cu API-ul altui sistem de operare. Această abordare este uneori numită traducere pentru a o diferenția de procesul mai lent de emulare a codului câte o instrucțiune pe rând.

De exemplu, pentru un program Windows care rulează pe un Macintosh, la interpretarea comenzilor de la un procesor Intel 80x86, performanța poate fi foarte slabă. Dar când se apelează funcția GUI de deschidere a ferestrei, modulul OS care implementează aplicația Mediul Windows, poate intercepta acest apel și îl redirecționează către un recompilat pentru procesorul Motorola 680x0 pentru a deschide o fereastră. Drept urmare, în astfel de secțiuni de cod, viteza programului poate atinge (și eventual depăși) viteza de lucru pe procesorul său „nativ”.

Pentru ca un program scris pentru un sistem de operare să ruleze pe un alt sistem de operare, nu este suficient doar să vă asigurați că API-ul este compatibil. Conceptele care stau la baza diferitelor sisteme de operare pot intra în conflict între ele. De exemplu, într-un sistem de operare, unei aplicații i se poate permite să controleze direct dispozitivele I/O, în altul, aceste acțiuni sunt apanajul sistemului de operare. Fiecare sistem de operare are propriile mecanisme de protecție a resurselor, propriile algoritmi de tratare a erorilor și excepțiilor, propria sa structură de proces și schemă de gestionare a memoriei, propria sa semantică de acces la fișiere și propria sa interfață grafică cu utilizatorul. Pentru a asigura compatibilitatea, este necesar să se organizeze o coexistență fără conflicte în cadrul aceluiași sistem de operare a mai multor moduri de gestionare a resurselor computerului.

Modalități de implementare a mediilor de aplicații software

Crearea unui mediu de aplicație cu drepturi depline, care este pe deplin compatibil cu mediul altui sistem de operare este o sarcină destul de complexă, strâns legată de structura sistemului de operare. Exista diverse opțiuni construirea de medii multiple de aplicații, care diferă atât prin caracteristicile soluțiilor arhitecturale, cât și prin funcționalitate, oferind un grad diferit de portabilitate a aplicațiilor.

În multe versiuni de UNIX, traducătorul de mediu de aplicație este implementat ca aplicare regulată. În sistemele de operare construite folosind conceptul de microkernel, cum ar fi Windows NT sau Workplace OS, mediile de aplicații rulează ca servere în modul utilizator. Și în OS/2, cu arhitectura sa mai simplă, mediile de aplicații sunt construite adânc în sistemul de operare.

Una dintre cele mai evidente opțiuni pentru implementarea mai multor medii de aplicații se bazează pe structura standard în straturi a sistemului de operare. Pe fig. 4 sistemul de operare OS1 suportă, pe lângă aplicațiile sale „native”, aplicații ale sistemelor de operare OS2 și OS3. Pentru a face acest lucru, conține aplicații speciale - medii de aplicații software - care traduc interfețele sistemelor de operare „străine” API OS2 și API OS3 în interfața sistemului lor de operare „nativ” - API OS1. De exemplu,

Dacă OS2 era sistemul de operare UNIX și OS1 era OS/2, pentru a executa apelul de sistem de creare a procesului forkO într-o aplicație UNIX, mediul de programare trebuie să apeleze nucleul sistemului de operare OS/2 cu apelul de sistem DosExecPgm().

Orez. patru. Medii de aplicații care traduc apelurile de sistem

Din păcate, comportamentul aproape tuturor funcțiilor care alcătuiesc API-ul unui sistem de operare, de regulă, diferă semnificativ de comportamentul funcțiilor corespunzătoare ale altui sistem de operare. De exemplu, pentru a face ca funcția de creare a procesului DosExecPgmO din OS/2 să fie exact aceeași cu funcția de creare a procesului forkO din sisteme asemănătoare UNIX, ar trebui modificat pentru a suporta capacitatea de a copia spațiul de adrese al unui proces părinte în cel al unui proces copil. (În comportamentul normal al acestei funcții, memoria procesului copil este inițializată pe baza datelor noului fișier executabil.)

Într-o altă implementare a mai multor medii de aplicații, sistemul de operare are mai multe interfețe de programare a aplicațiilor de la egal la egal. În fig. 5, sistemul de operare acceptă aplicații scrise pentru OS1, OS2 și OS3. Pentru a face acest lucru, direct în spațiul kernel al sistemului, aplicat interfețe software toate aceste sisteme de operare: API OS1, API OS2 și API OS3.

În această variantă, funcțiile de nivel API apelează funcțiile nivelului OS de bază, care trebuie să suporte toate cele trei medii de aplicații în general incompatibile. Diferite sisteme de operare gestionează timpul sistemului în moduri diferite, utilizați format diferit ora din zi, timpul procesorului este împărțit pe baza propriilor algoritmi etc. Funcțiile fiecărui API sunt implementate de kernel, ținând cont de specificul sistemului de operare corespunzător, chiar și

dacă au acelaşi scop. De exemplu, după cum sa menționat deja, funcția de creare a procesului funcționează diferit pentru o aplicație UNIX și o aplicație OS/2. În mod similar, la terminarea unui proces, nucleul trebuie, de asemenea, să determine ce sistem de operare este acest proces. Dacă acest proces a fost creat la cererea unei aplicații UNIX, atunci în timpul încheierii sale, nucleul trebuie să trimită un semnal către procesul părinte, așa cum se face în sistemul de operare UNIX. Și când un proces OS/2 creat cu opțiunea EXEC_SYNC se termină, nucleul ar trebui să rețină că ID-ul procesului nu poate fi reutilizat de un alt proces OS/2. Pentru ca nucleul să aleagă opțiunea dorită implementarea apelului de sistem, fiecare proces trebuie să transmită nucleului un set de caracteristici de identificare.

https://pandia.ru/text/78/240/images/image006_0.jpg" width="527" height="282 src=">

Orez. 6. Abordare microkernel pentru implementarea mai multor medii de aplicații

Crearea în cadrul unui sistem de operare a mai multor medii de aplicații pentru executarea aplicațiilor diferitelor sisteme de operare este o modalitate care vă permite să aveți o singură versiune a programului și să o transferați între sisteme de operare. Mai multe medii de aplicații asigură compatibilitatea binară a unui anumit sistem de operare cu aplicațiile scrise pentru alte sisteme de operare. Drept urmare, utilizatorii au mai multă libertate de a alege sistemele de operare și acces mai ușor la software de calitate.

Cele mai multe sisteme de operare moderne sunt sisteme modulare bine structurate care pot fi dezvoltate, extinse și portate pe noi platforme. OS monolitic(UNIX sau Novell NetWare) utilizează un nucleu monolitic care este legat ca un singur program care rulează în modul privilegiat. Un nucleu monolitic este un set de proceduri, fiecare dintre acestea putând apela fiecare. Toate procedurile rulează în modul privilegiat. Astfel, un nucleu monolitic este o astfel de schemă de sistem de operare, în care toate componentele sale sunt componente ale unui singur program, utilizează structuri generale date și interacționează între ele apelând direct proceduri. Pentru un sistem de operare monolitic, nucleul este același cu întregul sistem. În multe sisteme de operare cu un nucleu monolitic, asamblarea nucleului, adică compilarea lui, se realizează separat pentru fiecare computer pe care este instalat sistemul de operare. În acest caz, puteți selecta o listă de protocoale hardware și software, al căror suport va fi inclus în kernel. Deoarece nucleul este un singur program, recompilarea este singura modalitate de a adăuga noi componente la el sau de a le elimina pe cele neutilizate.

Arhitectura micronucleara

Concept

Arhitectura microkernel este o alternativă la modul clasic de a construi un sistem de operare. Arhitectura clasică în acest caz se referă la organizarea structurală a sistemului de operare discutată mai sus, conform căreia toate funcțiile principale ale sistemului de operare care alcătuiesc nucleul multistrat sunt realizate în mod privilegiat. În același timp, unele funcții auxiliare ale sistemului de operare sunt concepute ca aplicații și rulează în modul utilizator împreună cu programele utilizator obișnuite (devenind utilitare de sistem sau programe de procesare). Fiecare aplicație în modul utilizator rulează în propriul spațiu de adrese și este astfel protejată de orice interferență a altor aplicații. Codul kernel care se execută în modul privilegiat are acces la zonele de memorie ale tuturor aplicațiilor, dar este el însuși complet protejat de acestea. Aplicațiile accesează nucleul cu solicitări de a executa funcțiile sistemului.

Esența arhitecturii micronucleare este următoarea. Doar o parte foarte mică a sistemului de operare, numită microkernel, rămâne rulând în modul privilegiat (Figura 3.10). Microkernel-ul este protejat de restul sistemului de operare și al aplicațiilor. Microkernel-ul include, de obicei, module dependente de mașină, precum și module care îndeplinesc funcții de bază (dar nu toate!) Kernel-ul pentru gestionarea proceselor, gestionarea întreruperilor, gestionarea memoriei virtuale, redirecționarea mesajelor și controlul dispozitivelor I/O legate de încărcarea sau citirea registrelor. dispozitive. Setul de funcții al unui microkernel corespunde de obicei cu funcțiile stratului de mecanisme de bază ale unui nucleu obișnuit. Astfel de funcții ale sistemului de operare sunt dificil, dacă nu imposibil, de realizat în spațiul utilizatorului.

Orez. 3.10. Portarea cea mai mare parte a funcțiilor kernelului în spațiul utilizatorului

Toate celelalte funcții ale nucleului de nivel superior sunt împachetate ca aplicații în modul utilizator. Nu există o decizie clară cu privire la care dintre funcțiile sistemului ar trebui lăsată în modul privilegiat și care ar trebui mutată în modul utilizator. În general, mulți dintre managerii de resurse care sunt parte integrantă a nucleului obișnuit - sistemul de fișiere, memoria virtuală și subsistemele de gestionare a proceselor, managerul de securitate și așa mai departe - devin module „periferice” în modul utilizator.

O situație complet diferită apare atunci când o parte a sistemului de operare este oficializată sub forma unei aplicații. Prin definiție, scopul principal al unei astfel de aplicații este acela de a servi solicitări de la alte aplicații, cum ar fi crearea unui proces, alocarea memoriei, verificarea drepturilor de acces la o resursă etc. De aceea, managerii de resurse plasați în modul utilizator se numesc servere OS, adică module, scopul principal care este de a deservi cererile de la aplicații locale și alte module OS. Evident, pentru a implementa o arhitectură microkernel, o condiție necesară este prezența în sistemul de operare a unui mod convenabil și eficient de a apela procedurile unui proces din altul. Suportul pentru un astfel de mecanism este una dintre sarcinile principale ale microkernel-ului.

Schematic, mecanismul de accesare a funcțiilor OS, concepute ca servere, este următorul (Fig. 3.11). Clientul, care poate fi fie un program de aplicație, fie o altă componentă a sistemului de operare, solicită executarea unei anumite funcții de la serverul corespunzător, trimițându-i un mesaj. Mesageria directă între aplicații nu este posibilă deoarece spațiile lor de adrese sunt izolate unele de altele. Un microkernel care rulează în modul privilegiat are acces la spațiile de adrese ale fiecăreia dintre aceste aplicații și, prin urmare, poate acționa ca intermediar. Microkernel-ul trimite mai întâi un mesaj care conține numele și parametrii procedurii apelate către serverul dorit, apoi serverul efectuează operația solicitată, după care nucleul returnează rezultatele clientului cu un alt mesaj. Astfel, funcționarea unui sistem de operare microkernel corespunde binecunoscutului model client-server, în care rolul vehiculelor este îndeplinit de microkernel.

Orez. 3.11. Implementarea apelurilor de sistem în arhitectura microkernel

Avantajele și dezavantajele arhitecturii microkernel

Sistemele de operare bazate pe conceptul de microkernel îndeplinesc majoritatea cerințelor pentru sistemele de operare moderne într-un grad înalt, fiind portabile, extensibile, fiabile și creând o condiție prealabilă bună pentru susținerea aplicațiilor distribuite. Aceste beneficii vin cu prețul unei performanțe reduse, iar acesta este principalul dezavantaj al arhitecturii microkernel-ului.

Gradul ridicat de portabilitate se datorează faptului că tot codul dependent de mașină este izolat în microkernel, astfel încât pentru a porta sistemul la procesor nou sunt necesare mai puține modificări și toate sunt grupate logic împreună.

Extensibilitatea este inerentă unui sistem de operare microkernel într-un grad foarte ridicat. În sistemele tradiționale, chiar și în prezența unei structuri multistrat, nu este ușor să eliminați un strat și să îl schimbați cu altul din cauza multiplicității și estompării interfețelor dintre straturi. Adăugarea de noi funcții și modificarea celor existente necesită o bună cunoaștere a sistemului de operare și mult timp. În același timp, un set limitat de interfețe microkernel bine definite deschide calea pentru creșterea și evoluția ordonată a sistemului de operare. Adăugarea unui nou subsistem necesită dezvoltarea unei noi aplicații, care nu afectează în niciun fel integritatea microkernel-ului. Structura microkernelului permite nu numai adăugarea, ci și reducerea numărului de componente ale sistemului de operare, ceea ce poate fi și foarte util. De exemplu, nu toți utilizatorii au nevoie de caracteristici de securitate sau suport pentru calcularea distribuită, iar eliminarea acestora din nucleul tradițional este adesea imposibilă. În mod obișnuit, sistemele de operare tradiționale vă permit să adăugați sau să eliminați în mod dinamic driverele de dispozitive externe la kernel - datorită modificărilor frecvente în configurația dispozitivelor externe conectate la computer, subsistemul I/O kernel permite încărcarea și descărcarea driverelor „din zbor” , dar pentru aceasta este dezvoltat într-un mod special (de exemplu, mediul STREAM pe UNIX sau managerul I/O pe Windows NT). Cu o abordare microkernel, configurabilitatea sistemului de operare nu provoacă probleme și nu necesită măsuri speciale - este suficient să schimbați fișierul cu setările inițiale de configurare a sistemului sau să opriți serverele care nu mai sunt necesare în timpul funcționării folosind mijloacele obișnuite pentru a opri aplicațiile.

Utilizarea modelului microkernel crește fiabilitatea sistemului de operare. Fiecare server rulează ca un proces separat în propria zonă de memorie și este astfel protejat de alte servere ale sistemului de operare, ceea ce nu se vede într-un sistem de operare tradițional în care toate modulele nucleului se pot influența reciproc. Și dacă un singur server se prăbușește, acesta poate fi repornit fără a opri sau a deteriora restul serverelor OS. Mai mult, din moment ce serverele rulează în modul utilizator, acestea nu au acces direct la hardware și nu pot modifica memoria care stochează și rulează microkernel-ul. O altă sursă potențială de fiabilitate îmbunătățită a sistemului de operare este cantitatea redusă de cod microkernel în comparație cu un nucleu tradițional, ceea ce reduce șansa de erori de programare.

Modelul microkernel este foarte potrivit pentru a suporta calculul distribuit, deoarece folosește mecanisme similare celor de rețea: interacțiunea clienților și serverelor prin schimbul de mesaje. Serverele Microkernel OS pot rula pe același computer sau pe computere diferite. În acest caz, atunci când un mesaj este primit de la o aplicație, microkernel-ul îl poate procesa singur și îl poate trimite la serverul local sau îl poate trimite prin rețea către microkernel-ul care rulează pe alt computer. Trecerea la procesarea distribuită necesită modificări minime în funcționarea sistemului de operare - doar transportul local este înlocuit cu unul de rețea.

Performanţă. Cu organizarea clasică a OS (Fig. 3.12, a), execuția unui apel de sistem este însoțită de două moduri de comutare și cu o organizare micronucleară (Fig. 3.12, 6) - patru. Astfel, un sistem de operare bazat pe un microkernel, ceteris paribus, va fi întotdeauna mai puțin productiv decât un sistem de operare cu un nucleu clasic. Din acest motiv, abordarea micronucleului nu a fost adoptată la fel de pe scară largă pe cât se prevedea.

Orez. 3.12. Schimbarea modurilor la efectuarea unui apel de sistem

Severitatea acestui neajuns este bine ilustrată de istoria dezvoltării Windows NT. În versiunile 3.1 și 3.5, managerul de ferestre, biblioteca grafică și driverele de dispozitiv grafic de nivel înalt făceau parte din serverul în modul utilizator, iar funcțiile acestor module erau apelate conform schemei microkernel-ului. Cu toate acestea, dezvoltatorii Windows NT și-au dat seama curând că un astfel de mecanism de apelare a funcțiilor utilizate frecvent ale interfeței grafice încetinește semnificativ aplicațiile și face acest sistem de operare vulnerabil la concurența intensă. Ca urmare, au fost aduse modificări semnificative versiunii Windows NT 4.0 - toate modulele enumerate mai sus au fost transferate în nucleu, ceea ce a îndepărtat acest sistem de operare de arhitectura ideală a microkernelului, dar i-a crescut dramatic performanța.

gestionarea spațiului de adrese de memorie virtuală.

managementul proceselor și firelor de execuție (threads).

mijloace de comunicare între procese .

Toate celelalte servicii OS furnizate direct de nucleu în nucleele monolitice clasice sunt implementate în spațiul de adrese al utilizatorului (Ring3) în arhitecturile microkernel și se numesc servicii. Exemple de astfel de servicii aduse în spațiul utilizatorului în arhitecturile microkernel sunt serviciile de rețea, sistemul de fișiere, driverele.

Principalul avantaj al arhitecturii microkernel este gradul ridicat de modularitate al nucleului sistemului de operare. Acest lucru simplifică foarte mult adăugarea de noi componente la acesta. Într-un sistem de operare microkernel, puteți încărca și descărca noi drivere, sisteme de fișiere etc. fără a întrerupe funcționarea acestuia.Procesul de depanare a componentelor kernelului este mult simplificat, deoarece o nouă versiune driverele pot fi încărcate fără a reporni întregul sistem de operare. Componentele nucleului sistemului de operare nu sunt fundamental diferite de programele utilizatorului, așa că puteți folosi instrumentele obișnuite pentru a le depana. Arhitectura microkernel-ului îmbunătățește fiabilitatea sistemului, deoarece o eroare la nivel de program fără privilegii este mai puțin periculoasă decât o defecțiune în modul kernel.

Și pentru a adăuga un driver de dispozitiv la un sistem de operare cu microkernel, nu trebuie să recompilați întregul nucleu, ci trebuie doar să compilați separat acest driver și să-l rulați în spațiul utilizatorului.

În același timp, arhitectura microkernel a sistemului de operare introduce o suprasarcină suplimentară de mesagerie, care are un impact negativ asupra performanței. Pentru ca un sistem de operare microkernel să fie la fel de rapid ca sistemele de operare monolitice cu nucleu, este necesar să proiectați cu atenție partiționarea sistemului în componente, încercând să minimizați interacțiunea dintre ele. Astfel, principala dificultate în crearea sistemelor de operare microkernel este necesitatea unui design foarte atent.

Symbian OS este un exemplu clasic de sistem microkernel. Acesta este un exemplu de sistem de operare microkernel comun și matur (și începând cu Symbian OS v8.1 și nanokernel).

Creatorii Symbian OS au reușit să combine eficiența și armonia conceptuală, în ciuda faptului că versiunile moderne ale acestui sistem oferă caracteristici extinse, inclusiv instrumente pentru lucrul cu date în flux, stive de protocoale care sunt esențiale pentru latența kernelului, grafică și video de înaltă definiție) . Dezvoltatorii Symbian au mutat aproape toate sarcinile aplicate (adică dincolo de competența de bază) în module de server care operează în spațiul de adrese al utilizatorului.

În Windows NT versiunile 3.x, a fost utilizată o arhitectură microkernel cu un proces de service pentru subsistemul grafică și interfață cu utilizatorul. În special, driverul hardware grafic a fost încărcat în contextul procesului de serviciu, nu în nucleu. De la versiunea 4, acest lucru a fost depreciat, procesul de service a fost reținut numai pentru gestionarea ferestrelor consolei Linie de comanda, iar subsistemul grafic în sine, împreună cu driverul hardware (inclusiv grafica tridimensională), s-au mutat într-o regiune special izolată a nucleului sistemului de operare.

Windows CE (și se bazează pe acesta, cum ar fi Windows Mobile), deși aproape complet compatibil (ca subset) cu Windows NT în ceea ce privește apelurile și metodele de programare a aplicațiilor, este totuși complet diferit de Windows NT în arhitectura internă și este un sistem de operare microkernel. cu eliminarea tuturor driverelor de dispozitiv, a stivelor de rețea și a subsistemului grafic în procesele de service.

Dezavantajul este costul forțării unei „comutații” de procese în kernel (comutație de context); acest fapt explică de fapt dificultățile în proiectarea și scrierea nucleelor unui astfel de design. Aceste deficiențe sunt capabile să ocolească sistemele de operare care utilizează arhitectura exokernel, care este o dezvoltare ulterioară a arhitecturii microkernel.

Vezi si

micronuclee

OS bazat pe microkernel-uri

Fundația Wikimedia. 2010 .

Sinonime:

Vedeți ce este „Microkernel” în alte dicționare:

Microkernel... Dicţionar de ortografie

Partea centrală a sistemului de operare care îndeplinește principalele funcții de management al sistemului: managementul memoriei virtuale; suport pentru executarea procesului; organizarea interacțiunii între procese; întreținerea datelor I/O și a întreruperilor. De… … Vocabular financiar- Acest termen are alte semnificații, vezi L4. Acest articol ar trebui să fie wikificat. Vă rugăm să-l formatați conform regulilor de formatare a articolelor... Wikipedia

Textul prelegerii

Întrebări cheie

Cursul numărul 2. Arhitectura sistemelor de operare. Partea 1

Scopul și obiectivele cursului.

· Informații și date.

· Concepte și definiții de bază: sisteme de operare pe disc (DOS); OS scop general; sisteme de tipuri intermediare, sisteme de mașini virtuale; sisteme în timp real; Sisteme de dezvoltare încrucișată; sisteme de tipuri intermediare.

· Concepte și definiții de bază: Microkernel.

· Istoria dezvoltării sistemelor.

· Scopul și componentele principale ale SBD.

· Sisteme de operare monolitice.

Structura și complexitatea sistemelor de operare se schimbă semnificativ pe măsură ce atât sistemele de operare, cât și hardware-ul evoluează. Sistemul de operare CTSS, dezvoltat la Massachusetts Institute of Technology (MIT) în 1963, a ocupat aproximativ 36.000 de cuvinte pe 36 de biți în memorie. OS/360, dezvoltat de IBM un an mai târziu, conținea peste un milion de instrucțiuni ale mașinii. Sistemul Multics, dezvoltat în comun de MIT și Bell Laboratories în 1975, conținea deja aproximativ 20 de milioane de instrucțiuni.

Creșterea dimensiunii și complexității sistemelor de operare a condus la trei probleme comune:

Sistemele de operare ajung la utilizator cu o întârziere semnificativă,

Există erori ascunse în sisteme care trebuie corectate,

Creșterea performanței sistemelor de operare nu este atât de mare pe cât ne-am dori.

Modalitățile de a rezolva aceste probleme, în general, sunt destul de evidente:

Sistemul ar trebui să fie format din module - acest lucru simplifică scrierea și depanarea,

Modulele ar trebui să aibă interfețe proiectate cu atenție și cât mai simple posibil - acest lucru facilitează, de asemenea, scrierea și depanarea, precum și modificarea sistemului.

În ciuda faptului că o astfel de soluție este evidentă, s-a dovedit că pentru sistemele complexe constând din milioane sau mai multe linii, nu elimină toate problemele.

Structura sistemului de operare depinde în mare măsură de tipul căruia îi aparține. Există multe tipuri de sisteme de operare, dar, în general, se pot distinge următoarele:

micronucleare,

monolitic,

pe mai multe niveluri,

Mașini virtuale,

Exokernel,

model client-server.

microkernel este partea minimă a sistemului de operare, care stă la baza extensiilor modulare și portabile. Ideea principală a microkernel-ului este de a crea mediul necesar nivel superior, de la care puteți accesa toate funcțiile nivelului hardware.

Microkernel-ul conține cantitatea minimă de cod necesară pentru implementarea apelurilor de sistem de bază. Aceste apeluri includ transmiterea de mesaje și alte comunicări între procese externe nucleului, gestionarea întreruperilor și alte funcții. Funcțiile rămase sunt implementate ca completări modulare care interacționează între ele folosind mesaje.

Microkernel-ul rulează cu cea mai mare prioritate și rulează restul sistemului de operare ca un set de aplicații server. Tehnologia microkernelului Mach (Mac) a fost creată la Universitatea Carnegie Mellon și stă la baza multor sisteme de operare.

Funcționalitatea microkernel-ului este limitată pentru a-și reduce dimensiunea și a transfera cea mai mare parte a sistemului de operare la rangul unui program de aplicație. Un microkernel acceptă de obicei cinci tipuri variate Servicii:

managementul memoriei virtuale,

Gestionarea jobului și a firelor de discuție,

Comunicații între procese (IPC - inter-process communication),

managementul I/O și întreruperi,

Furnizarea serviciului client-server.

Alte funcții ale sistemului de operare sunt găzduite în alte servicii OS care rulează ca aplicații microkernel.

Esența arhitecturii micronucleare este următoarea. Doar o parte foarte mică a sistemului de operare, numită microkernel, rulează în modul privilegiat. Microkernel-ul este protejat de restul sistemului de operare și de aplicații. Setul de funcții al microkernelului corespunde funcțiilor stratului de mecanisme de bază ale nucleului convențional. Acestea sunt funcțiile care nu pot fi efectuate în modul utilizator. Figura 1.2 prezintă mecanismul pentru mutarea cea mai mare parte a funcționalității nucleului în spațiul utilizatorului.

Datorită dimensiunii și capacității sale de a suporta servicii de programare standard, microkernel-ul este mai simplu decât nucleele sistemelor de operare monolitice sau modulare.

Figura 4.1 - Transferul majorității funcțiilor kernelului în spațiul utilizatorului

Toate celelalte funcții ale nucleului sunt ambalate ca aplicații care rulează în modul utilizator. Nu există recomandări clare despre care dintre funcțiile sistemului ar trebui efectuate în modul privilegiat și care în modul utilizator.

Managerii de resurse în modul utilizator sunt numiți servere OS, deoarece scopul lor principal este de a deservi cererile de la aplicații și alte module OS. Pentru a implementa acest mecanism, este necesar ca sistemul de operare să aibă o modalitate eficientă de a apela procedurile unui proces din altul. Suportul pentru acest mecanism este funcția principală a microkernel-ului.

Figura 4.2 prezintă mecanismul de accesare a funcțiilor OS concepute ca servere. Clientul, care poate fi fie un program de aplicație, fie o altă componentă a sistemului de operare, solicită executarea unei anumite funcții de la serverul corespunzător, trimițându-i un mesaj. Mesageria directă între aplicații nu este posibilă deoarece spațiile lor de adrese sunt izolate unele de altele. Un microkernel care rulează în modul privilegiat are acces la toate spațiile de adrese, astfel încât poate acționa ca intermediar. Astfel, funcționarea unui sistem de operare microkernel corespunde modelului client-server, în care rolul vehiculelor este îndeplinit de microkernel.

Cel mai reprezentant de seamă microkernel OS este sistemul de operare QNX în timp real. Microkernel-ul QNX programează doar programarea și expedierea proceselor, comunicarea acestora, gestionarea întreruperilor și serviciile de rețea de nivel inferior. Un astfel de microkernel oferă doar două duzini de apeluri de sistem și are o dimensiune de la 8 la 46 de kiloocteți.

Figura 4.2 - Implementarea unui apel de sistem într-o arhitectură microkernel

Pentru a construi un sistem QNX minim, adăugați un manager de proces la microkernel care creează procese, le gestionează și le gestionează memoria. Pentru a utiliza QNX pe un computer desktop, microkernel-ul trebuie, de asemenea, completat cu Sistemul de fișiereși manager de dispozitive.

Toți acești manageri rulează în afara spațiului de kernel, astfel încât nucleul rămâne mic.

Luați în considerare pe scurt avantajele și dezavantajele sistemelor de operare microkernel. Avantajele lor includ:

Portabilitate, datorită faptului că tot codul dependent de mașină este izolat în microkernel,

Extensibilitate datorită unui set limitat de interfețe microkernel bine definite; adăugarea unui nou subsistem necesită dezvoltarea unei noi aplicații, care nu afectează în niciun fel integritatea microkernel-ului,

Fiabilitate datorită faptului că fiecare server rulează ca un proces separat în propria zonă de memorie, care îl protejează de alte servere OS (într-un sistem de operare tradițional, toate modulele se pot influența reciproc); cantitatea redusă de cod microkernel contribuie, de asemenea, la creșterea fiabilității,

Adecvarea pentru calculul distribuit, deoarece folosește mecanismele de interacțiune client-server, iar serverele OS microkernel pot fi localizate atât pe același computer, cât și pe computere diferite.

Principalul dezavantaj al unui sistem de operare microkernel este performanța sa redusă în comparație cu un sistem de operare clasic. Faptul este că, odată cu organizarea clasică a sistemului de operare, execuția unui apel de sistem este însoțită de două moduri de comutare și cu o arhitectură microkernel - patru. Situația este ilustrată în Figura 4.3.

Figura 4.3 - Schimbarea modurilor la efectuarea unui apel de sistem

Severitatea acestui neajuns este bine ilustrată de istoria dezvoltării Windows NT. În versiunile 3.1 și 3.5, managerul de ferestre, GUI și driverele de dispozitiv grafic de nivel înalt au fost incluse în serverul în modul utilizator, iar aceste funcții au fost invocate conform schemei microkernel-ului. Cu toate acestea, dezvoltatorilor a devenit clar că un astfel de mecanism reduce semnificativ performanța sistemului, așa că în versiunea 4.0 modulele enumerate mai sus au fost incluse în kernel. Acest fapt a îndepărtat sistemul de operare de arhitectura ideală de microkernel, dar a făcut sistemul mai productiv.

În sistemele de operare microkernel, putem evidenția un modul compact central care aparține părții de supraveghere a sistemului. Acest modul este foarte mic și realizează un număr relativ mic de funcții de control, dar vă permite să transferați controlul către alte module de control, care vor îndeplini funcția solicitată. Microkernel-ul este cea mai mică parte principală (de bază) a sistemului de operare, care servește drept bază pentru extensii modulare și portabile. Microkernel-ul în sine este un modul de sistem software, care operează în starea de cea mai mare prioritate a computerului și menține comunicațiile cu restul sistemului de operare, care este considerat ca un set de aplicații (servicii) server.

În anii 1990, a existat o credință larg răspândită că majoritatea sistemelor de operare de generație următoare vor fi construite ca microkernel-uri. Cu toate acestea, practica arată că acest lucru nu este în întregime adevărat. Dezvoltatorii doresc să aibă un microkernel compact, dar în același timp să includă cât mai multe funcții care sunt realizate direct de acest modul software. Pentru execuția funcției solicitate de către un alt modul numit din microkernel duce atât la întârzieri suplimentare, cât și la complexități suplimentare. Mai mult, există multe opinii diferite despre modul în care ar trebui să fie organizate serviciile sistemului de operare în raport cu microkernel-ul; cum să proiectați driverele de dispozitiv pentru a fi cât mai eficiente posibil, dar să păstreze funcțiile

290______________________________ Capitolul 9 Arhitectura sistemului de operare

driverele sunt cât mai independente de hardware; dacă operațiunile non-kernel ar trebui efectuate în spațiul kernel sau spațiul utilizatorului; dacă merită să păstrezi programele subsistemelor existente (de exemplu, UNIX) sau este mai bine să renunți la tot și să începi de la zero.

Ideea principală din spatele tehnologiei microkernel este de a crea mediul necesar la nivelul superior al ierarhiei, din care puteți accesa cu ușurință toate funcţionalitate nivelul hardware. În același timp, microkernel-ul este punctul de plecare pentru crearea tuturor celorlalte module ale sistemului. Toate aceste alte module care implementează funcțiile necesare sistemului sunt apelate din microkernel și îndeplinesc un rol de serviciu. Procedând astfel, ei primesc statutul unui proces sau sarcină normală. Putem spune că arhitectura microkernel corespunde tehnologiei client-server. Această tehnologie este cea care face posibilă implementarea principiilor de mai sus de proiectare a sistemelor de operare într-o măsură mai mare și cu costuri de muncă mai mici.

Cea mai importantă sarcină a dezvoltării microkernel-ului este alegerea primitivelor de bază care trebuie să fie în microkernel pentru a oferi serviciul necesar și suficient. Microkernel-ul conține și execută cantitatea minimă de cod necesară pentru implementarea apelurilor de sistem de bază. Aceste apeluri includ transmiterea de mesaje și alte comunicări între procese externe microkernel-ului, suport pentru gestionarea întreruperilor și alte câteva funcții foarte puține. Restul funcțiilor de sistem care sunt specifice sistemelor de operare „obișnuite” (non-microkernel) sunt furnizate ca procese adiționale modulare care interacționează în primul rând între ele și comunică prin transmiterea mesajelor.

Pentru majoritatea sistemelor de operare cu microkernel, baza acestei arhitecturi este tehnologia Mach microkernel. Acest sistem de operare a fost creat la Universitatea Carnegie Mellon și mulți dezvoltatori s-au inspirat de la el.

Funcțiile realizate de microkernel sunt limitate pentru a reduce dimensiunea acestuia și a maximiza cantitatea de cod care rulează ca un program de aplicație. Microkernel-ul include doar acele funcții care sunt necesare în scopul definirii unui set de medii abstracte de procesare pentru aplicații și organizare. munca în comun aplicatii. Ca rezultat, microkernel-ul oferă doar cinci tipuri diferite de servicii:

Gestionarea memoriei virtuale;

Suport pentru lucrări și fire;

Interacțiunea între procese (Inter-Process Communication, IPC);
- gestionarea suportului I/O și a întreruperilor;

Servicii de gazdă 1 și procesor.

1 gazdă - calculatorul principal. Astăzi, acest termen se referă la orice computer care are o adresă IP.

Sisteme de operare microkernel________________ 291

Alte subsisteme și funcții ale sistemului de operare, cum ar fi sistemele de fișiere, suportul pentru dispozitive externe și interfețele tradiționale de programare, sunt furnizate ca servicii de sistem sau au statutul de sarcini obișnuite de procesare. Aceste programe rulează ca aplicațiile microkernel.

Folosind conceptul de fire multiple de execuție per job, microkernel-ul creează un mediu de aplicație care permite utilizarea multiprocesoarelor; cu toate acestea, nu este deloc necesar ca mașina să fie multiprocesor: pe o mașină cu uniprocesor, diferite fire rulează pur și simplu în momente diferite. Tot suportul necesar pentru mașinile multiprocesor este concentrat într-un microkernel relativ mic și simplu.

Datorită dimensiunilor reduse și capacității lor de a sprijini alte servicii ca procese obișnuite care rulează împreună cu programele de aplicație, microkernel-urile în sine sunt mai simple decât nucleele monolitice sau modulare ale sistemului de operare. Cu microkernel-ul, partea de supraveghere a sistemului de operare este împărțită în părți modulare care pot fi configurate în mai multe moduri, permițându-vă să construiți sisteme mari adăugând piese la cele mai mici. De exemplu, fiecare serviciu neutru independent de dispozitiv este separat logic și poate fi configurat căi diferite. De asemenea, microkernel-urile facilitează suportul multiprocesoarelor prin crearea unui mediu de programare standard care poate folosi mai multe procesoare dacă sunt disponibile, dar dacă nu, rulează pe unul singur. Codul specializat pentru multiprocesoare este limitat la microkernel-ul însuși. Mai mult, rețelele de microkernel-uri care comunică între ele pot fi utilizate pentru suportul sistemului de operare al clasei emergente de mașini masiv paralele.

În unele cazuri, utilizarea abordării microkernel în practică întâmpină anumite dificultăți, care se manifestă printr-o oarecare încetinire a vitezei de executare a apelurilor de sistem la trecerea mesajelor prin microkernel în comparație cu abordarea clasică. Pe de altă parte, se poate afirma și contrariul. Deoarece microkernel-urile sunt mici și extrem de optimizate, în anumite condiții pot oferi performanța în timp real necesară pentru controlul dispozitivului și comunicațiile de mare viteză. În cele din urmă, microkernel-urile bine structurate oferă un strat izolator pentru diferențele hardware care nu sunt mascate de utilizarea limbajelor de programare de nivel înalt. Astfel, ele facilitează portarea codului și sporesc reutilizarea acestuia.

Cel mai proeminent reprezentant al sistemelor de operare microkernel este sistemul de operare în timp real QNX. Microkernel-ul QNX acceptă numai programarea și expedierea proceselor, comunicarea proceselor, gestionarea întreruperilor și servicii de rețea de nivel scăzut (a se vedea capitolul 10 pentru mai multe despre QNX). Acest microkernel oferă doar câteva zeci de apeluri de sistem, dar datorită acestui lucru, poate fi plasat complet în memoria cache internă chiar și a unor astfel de procesoare precum Intel 486. După cum știți, versiuni diferite Acest sistem de operare a avut, de asemenea, diferite dimensiuni de nuclee - de la 8 la 46 KB.

292______________________________ Capitolul 9 Arhitectura sistemului de operare

Construirea unui sistem QNX minimal necesită adăugarea unui manager de proces la microkernel care creează și gestionează procesele și memoria de proces. Pentru a face sistemul de operare QNX utilizabil dincolo de sistemele încorporate și fără disc, trebuie să adăugăm un sistem de fișiere și un manager de dispozitive. Acești manageri rulează în afara spațiului de kernel, astfel încât nucleul rămâne mic.

Vezi si

Vedeți ce este „Microkernel” în alte dicționare:

Continut Asemanator: