Kernel: differenze tra le versioni

Versione delle 02:15, 20 dic 2004

Versione attuale delle 22:51, 7 ott 2025

(485 versioni intermedie di oltre 100 utenti non mostrate)

Riga 1:

{{Nota disambigua}}

In [[informatica]], il '''kernel''' è la parte fondamentale di un [[sistema operativo]]. Si tratta di un [[software]] con il compito di fornire ai programmi in esecuzione sul computer un accesso sicuro e controllato all'[[hardware]]. Siccome possono esserci più programmi in esecuzione simultanea e l'accesso all'hardware è limitato, il kernel ha anche la responsabilità di assegnare una porzione di tempo macchina e di accesso all'hardware a ciascun programma, funzione detta [[multiplexing]]. L'accesso diretto all'hardware può essere anche molto complesso, quindi i kernel usualmente implementano uno o più tipi di ''[[astrazione dell'hardware]]''. Queste astrazioni servono a "nascondere" la complessità e a fornire un'interfaccia pulita ed uniforme all'hardware sottostante, in modo da semplificare il lavoro degli sviluppatori software.

[[File:Kernel-simple.svg|thumb|Astrazione dal [[software]] all'[[hardware]] passando per il ''kernel'']]

In [[informatica]], il '''kernel''' ([[Alfabeto fonetico internazionale|AFI]]: {{IPA|[ˈkəːnəl]|en}}) o '''nucleo''' è un [[Programma (informatica)|programma]] situato al centro del [[sistema operativo]] che ha generalmente un controllo completo dell'intero sistema<ref name="Linfo">{{cita web|url=http://www.linfo.org/kernel.html|titolo=Kernel|sito=Linfo|editore=Bellevue Linux Users Group|accesso=15 settembre 2016|urlarchivio=https://web.archive.org/web/20061208185439/http://www.linfo.org/kernel.html|urlmorto=}}</ref> e fornisce un accesso sicuro e controllato dell'[[hardware]] ai [[processo (informatica)|processi]] in [[esecuzione (informatica)|esecuzione]] sul [[elaboratore|computer]].<ref>{{cita libro|autore=Brian Bagnall|titolo=On The Edge: The Spectacular Rise and Fall of Commodore|anno=2006|editore=Variant Press|lingua=en|p=202|ISBN=978-0-97-386490-8}}{{Citazione|Il kernel è la parte più fondamentale di un programma, normalmente un sistema operativo, che risiede in memoria per tutto il tempo e che fornisce i servizi di base: è la parte del sistema operativo che è più vicina alla macchina e che può attivare l'hardware direttamente oppure interfacciarsi con un altro livello software che gestisce l'hardware.||The kernel is the most fundamental part of a program, typically an operating system, that resides in memory at all times and provides the basic services. It is the part of the operating system that is closest to the machine and may activate the hardware directly or interface to another software layer that drives the hardware.|lingua=en}}</ref> Dato che possono eventualmente esserne eseguiti simultaneamente più di uno, il kernel può avere anche la responsabilità di assegnare una porzione di tempo-macchina (''[[scheduling]]'') e di accesso all'hardware a ciascun programma (''[[multitasking]]'')<ref>{{cita web|lingua=en|url=http://kukuruku.co/hub/opensource/multitasking-management-in-the-operating-system-kernel|titolo=Multitasking Management in the Operating System Kernel|autore=LifeV|data=13 maggio 2014|editore=Kukuruku.co|accesso=1º novembre 2016}}{{Citazione|Siccome in un dato momento ogni processore gestito dal kernel può eseguire solo una istruzione per volta, ci può essere solo un thread attivo. Il processo mediante il quale si sceglie il thread di calcolo attivo è chiamato scheduling. A sua volta, il modulo incaricato di fare questa scelta è detto scheduler.||Since only one instruction can be executed at one processor kernel at one moment, only one thread can be active. The process of chosing the active computing thread is called scheduling. In its turn, the module which is in charge of the choice is called the scheduler. |lingua=en}}</ref>.

<!-- An operating system kernel is not strictly needed to run a computer. Programs can be directly loaded and executed on the "bare metal" machine, provided that the authors of those programs are willing to do without any hardware abstraction or operating system support. This was the normal operating method of many early computers, which were reset and reloaded between the running of different programs. Eventually, small ancillary programs such as [[program loader]]s and [[debugger]]s were typically left in-core between runs, or loaded from [[read-only memory]]. As these were developed, they formed the basis of what became early operating system kernels. -->

I kernel si possono classificare in quattro categorie:

== Descrizione ==

Un kernel non è strettamente necessario per far funzionare un computer. I [[programma (informatica)|programmi]] possono essere infatti direttamente caricati ed eseguiti sulla macchina, a patto che i loro [[programmatore|sviluppatori]] ritengano necessario fare a meno del supporto del sistema operativo.

Questa era la modalità di funzionamento tipica dei primi computer, che venivano resettati prima di eseguire un nuovo programma. In un secondo tempo, alcuni programmi accessori come i program loader e i [[debugger]] venivano lanciati da una [[Read Only Memory|memoria a sola lettura]], o fatti risiedere in [[memoria (informatica)|memoria]] durante le transizioni del computer da un'[[Applicazione (informatica)|applicazione]] all'altra: essi formarono la base di fatto per la creazione dei primi sistemi operativi.

Un'altra situazione in cui l'assenza di sistema operativo è auspicabile è l'esempio dei [[Microcontrollore|microcontrollori]] monolitici.

L'accesso diretto al kernel da parte di un utente/[[sistemista|amministratore]] può avvenire in modalità [[user mode]] o [[kernel mode]].

== Classificazione ==

[[File:OS-structure2.svg|thumb|Confronto tra i diversi kernel]]

L'accesso diretto all'hardware può essere anche molto complesso, quindi i kernel usualmente implementano uno o più tipi di astrazione dall'hardware, il cosiddetto ''livello di astrazione dell'hardware'' (''[[hardware abstraction layer]]'' o ''HAL''). Queste astrazioni servono a "nascondere" la complessità e a fornire un'interfaccia pulita e uniforme all'hardware sottostante, in modo da semplificare il lavoro degli sviluppatori.

I kernel si possono classificare in quattro categorie, in base al grado di astrazione dell'hardware:

* ''Kernel monolitici'', che implementano direttamente una completa astrazione dell'hardware sottostante.

* ''Microkernel'', che forniscono un insieme ristretto e semplice di astrazione dell'hardware e usano sofwaresoftware (chiamati [[device driver]] o [[server]]) per fornire maggiori funzionalità.

* ''Kernel ibridi'' (o ''microkernel modificati''), che sonosi moltodifferenziano simili aidai microkernel puri tranne per ill'implementazione fattodi chealcune implementanofunzioni delaggiuntive codiceal aggiuntivo a livellofine di kernel per incrementare le prestazioni.

* ''Esokernel'', che rimuovono tutte le limitazioni legate all'astrazione dell'hardware e si limitano a garantire l'accesso concorrente allo stesso, permettendo alle singole applicazioni di implementare autonomamente le tradizionali astrazioni del sistema operativo per mezzo di speciali [[Libreria software|librerie]].

* ''Esokernel'', che non forniscono astrazione ma che permettono l'uso di [[libreria|librerie]] per fornire più funzionalità tramite un accesso diretto o quasi all'hardware.

=== Kernel monolitici ===

[[File:Kernel-monolithic.svg|thumb|Rappresentazione grafica di un kernel monolitico]]

L'approccio monolitico definicedefinisce un'interfaccia virtuale di alto livello sull'hardware e software, con un set di primitive o [[chiamata di sistema|chiamate di sistema]] per implementare servizi di sistema operativo come ''gestione dei processi'', ''multitasking'' e ''gestione della memoria'', in diversi moduli che girano in ''modalità supervisore''.

Anche se ogni modulo che serve queste operazioni è separato dal resto, l'integrazione del codice è molto stretta e difficile da fare in maniera corretta e, siccome tutti i moduli operano nello stesso spazio, un bug in uno di essi può bloccare l'intero sistema. Tuttavia, quando l'implementazione è completa e sicura, la stretta integrazione interna dei componenti rende un buon kernel monolitico estremamente efficiente. <!-- Proponents of the monolithic kernel approach make the case that if code is not correct, it does not belong in a kernel, and if it is, there is little advantage in the microkernel approach. -->

Il più grossoconsiderevole svantaggio dei kernel monolitici è tuttavia che non è possibile aggiungere un nuovo dispositivo hardware senza aggiungere il relativo modulo al kernel, operazione che richiede la ''[[Compilatore|ricompilazione del kernel'']]. In alternativa è possibile compilare un kernel con tutti i moduli di supporto all'hardware, ingigantendoal peròcosto ledi sueaumentarne molto la dimensionidimensione. Tuttavia i kernel monolitici più moderni come il [[KernelLinux (kernel)|kernel Linux]] e [[FreeBSD]] possono caricare dei moduli in fase di esecuzione, ase pattosono cheprevisti questiin fosserofase previstidi inconfigurazione (fase che precede quella di compilazione, durante la quale si può scegliere quali feature o driver debbano far parte del nuovo kernel), permettendo così l'estensione del kernel quando richiesto, mantenendo al contempo le dimensioni del codice nello spazio del kernel al minimo indispensabile.

Esempi di kernel monolitici:

* I tradizionali kernel [[UNIX]], quali ad esempio i kernel [[Berkeley Software Distribution|BSD]].

* Il [[Linux (kernel)|kernel Linux]].

* Kernel di ricerca come [[AGNIX]].

=== Microkernel ===

[[File:Kernel-microkernel.svg|thumb|Rappresentazione grafica di un microkernel]]

[[File:IBM AIX logo (2021).svg|thumb|Logo [[AIX (sistema operativo)|AIX]], sistema operativo, basato su microkernel]]

[[File:BeOS_screenshot.png|thumb|[[BeOS]], altro sistema operativo basato su microkernel]]

L'approccio microkernel consiste nel definire delleun [[macchinekernel virtuali]]principale moltoche semplicifornisce sopra l'hardware, conesclusivamente un set di ''primitive'' o [[chiamata di sistema|chiamate di sistema]] per implementare servizi minimali del sistema operativo quali ''gestione dei [[Thread (informatica)|thread'']], ''[[Spazio di indirizzamento|spazi di indirizzamento'']] o ''[[Comunicazione tra processi|comunicazione interprocesso'']]. Sopra tale kernel minimale (da cui il prefisso "micro") vengono innestati dei server, ovvero programmi separati dal kernel che comunicano con questo tramite le suddette chiamate di sistema per implementare le varie funzionalità del sistema.

L'obiettivo principale è la separazione delle implementazioni dei servizi di base dalle strutture operative del sistema. Per esempio, il processo di blocco (locking) dell'Inputinput/Outputoutput può essere implementato come modulo server a livello utente. Questi moduli a livello utente, usati per fornire servizi di alto livello al sistema, sono modulari e semplificano la struttura e la progettazione del kernel. Un servizio server che smette di funzionare non provoca il blocco dell'intero sistema, e può essere riavviato indipendentemente dal resto.

Vi sono alcuni tipi di microkernel che non possono essere definiti esattamente come tali, perché non implementano alcune funzioni sotto forma di server, sebbene siano caratterizzati da altre prerogative che definiscono i microkernel. Il più noto di essi è [[AmigaOS#Exec|Exec]], abbreviazione di Executive Multitasking (e il suo diretto successore [[AmigaOS#ExecSG|ExecSG]]) che è il kernel di [[AmigaOS]].

Esempi di microkernel:

* [[AIX]]

Esempi di microkernel e Sistemi operativi basati su microkernel:

* [[Exec]], usato in [[AmigaOS]]

* [[AIX (sistema operativo)|AIX]]

* [[Mach]], usato in [[GNU Hurd]] e [[Mac OS X]]

* [[Amoeba (sistema operativo)|Amoeba]]

* La famiglia di microkernel [[L4]]

* [[BeOS]] e il suo successore [[Haiku (sistema operativo)|Haiku]]

* [[ChorusOS|Chorus microkernel]]

* [[EROS]]

* FreeRTOS

* [[K42]]

* [[KeyKOS]] (a [[nanokernel]])

* [[LSE/OS]] (a [[nanokernel]])

* The [[L4 microkernel family]]

* [[Mach (kernel)|Mach]]<ref>Viene utilizzato inizialmente in [[GNU Hurd]] e non in [[MacOS]], che utilizza usa [[XNU]], che è un kernel ibrido modulare nato dall'unione di Mach e del kernel [[FreeBSD]].</ref>

* [[MERT]]

* [[Minix]]

* [[MorphOS]]

* [[QNX]]

* [[Quark]] usato in [[MorphOS]]

* [[RadiOS]]

* [[Redox (sistema operativo)|Redox]]

* [[BeOS]]

* [[Spring operating system]]

* [[Symbian OS]]

* [[VSTa]]

* [[HarmonyOS]]

=== Kernel monolitici e microkernel a: confronto ===

[[File:DragonFly_BSD_4.2.3_bootloader_screenshot.png|thumb|[[DragonFly BSD|DragonFly]]]]

I kernel monolitici sono spesso preferiti ai microkernel a causa del minor livello di complessità nel controllo dei codici di controllo in uno spazio di indirizzamento. Per esempio [[XNU]], il kernel di [[Mac OS XmacOS]], è basato su un kernel Mach 3.0 piùe componenti BSD nello stesso spazio di indirizzamento in modo da abbattere i tempi di latenza tipici dei microkernel. XNU risulta così un kernel dalle notevoli prestazioni poiché basato in parte su una soluzione ibrida e non può in ogni caso essere considerato un microkernel. Nella documentazione ufficiale di Apple si fa chiaro riferimento a XNU come Kernel Monolitico Modulare.

A partire dai primi [[anni '901990|anni novanta]] i kernel monolitici sono considerati obsoleti. Il progetto di [[Kernel Linux (kernel)|kernel Linux]] come kernel monolitico anziché come microkernel è stato uno degli argomenti della famosa ''guerra di religione'' fra [[Linus Torvalds]] (il creatore di [[Linux (kernel)|Linux]]) e [[Andrew S.Stuart Tanenbaum|Andrew Tanenbaum]] (celebre docente di sistemi operativi, autore di [[Minix]] e padre del linguaggio [[Pascal]]) - in rete sono [httphttps://wwworeilly.dina.dkcom/catalog/opensources/~abrahambook/Linus_vs_Tanenbaumappa.html disponibili] maggiori dettagli.

In realtà vi sono ragioni da entrambe le parti.

I kernel monolitici tendono ad essere più semplici da progettare correttamente, e possono quindi evolversi più rapidamente di un sistema basato su microkernel. Ci sono storie di successi in entrambi gli schieramenti. I microkernel sono spesso usati in [[Sistema embedded|sistemi embedded]] in applicazioni [[Sistema critico|mission critical]] di automazione robotica o di medicina, a causa del fatto che i componenti del sistema risiedono in aree di memoria separate, private e protette. Ciò non è possibile con i kernel monolitici, nemmeno con i moderni moduli caricabili.

A parte il kernel [[Mach (kernel)|kernel Mach]], che è il più noto microkernel di uso generico, molti altri microkernel sono stati sviluppati con scopi specifici. [[Kernel L3]] in particolare è stato creato per dimostrare che i microkernel non sono necessariamente lenti. La [[famiglia di microkernel [[L4]], successori di L3, dispongono di una implementazione chiamata [[Fiasco (informatica)|Fiasco]] in grado di eseguire il [[KernelLinux (kernel)|kernel Linux]] accanto agli altri processi di L4 in spazi di indirizzamento separati.

[[QNX]] è un sistema operativo presente sulle scene dai primi [[anni '801980|anni ottanta]] e dispone di una implementazione a microkernel davvero minimalista. Questo sistema ha avuto molto più successo di Mach nel raggiungere gli obiettivi del paradigma a microkernel. È usato in situazioni in cui al software non è concesso di sbagliare, ad esempio nei bracci robotici dello [[space shuttle]] o in macchine che lavorano il vetro dove un errore anche piccolo può costare centinaia di migliaia di Euro.

=== Kernel ibridi ===

In molti credono che, siccome Mach ha fallito nel compito di risolvere tutti i problemi per i quali i microkernel erano stati concepiti, l'intera tecnologia microkernel sia fallimentare ed inutile. Invece i sostenitori dei microkernel sostengono che questa sia una concezione poco aperta mentalmente e che sia diventata così popolare da essere ormai accettata come verità.

[[File:Kernel-hybrid.svg|thumb|Rappresentazione grafica di un kernel ibrido]]

== Kernel ibridi (microkernel modificati)==

I kernel ibridi sono essenzialmente dei microkernel che hanno del codice "non essenziale" al livello di spazio del kernel in modo che questo codice possa girare più rapidamente che se fosse implementato ad alto livello. Questo fu un compromesso adottato da molti sviluppatori di sistemi operativi prima che fosse dimostrato che i microkernel puri potevano invece avere performance elevate. Molti sistemi operativi moderni rientrano in questa categoria: [[Microsoft Windows]] è l'esempio più noto. Anche [[XNU]], il kernel di Mac OS X, è di fatto un microkernel modificato, per via dell'inclusione di codice BSD in un kernel basato su Mach. [[DragonFly BSD]] è stato il primo sistema BSD non basato su Mach ad adottare l'architettura a kernel ibrido.

AlcuneNon personesi confondonoconfonda il termine "kernel ibrido" con i kernel monolitici che possono caricare dei moduli dopo il [[boot. Questo non è corretto]], poiché "ibrido" implica che il kernel in questione condividacondivide concetti architetturali e meccanismi tipici sia dei kernel monolitici che dei microkernel, specialmente il passaggio di messaggi e la migrazione di porzioni di codice "non essenziale" a più alto livello, mantendendomantenendo a livello kernel solo il codice necessario per ragioni di prestazioni.

Esempi di kernel ibridi:

* [[Microsoft]] [[Windows NT]] che è usato su tutti i sistemi basati su NT

* [[XNU]] kernel del [[macOS]]

* [[DragonFly BSD]]

* Quark, il kernel di [[MorphOS]]

* [[ReactOS]]

* [[Haiku (sistema operativo)|Haiku]]

=== Esokernel ===

[[File:Kernel-exo.svg|thumb|Rappresentazione grafica di un Exokernel]]

Gli esokernel, o Exokernel, conosciuti anche come "sistemi operativi verticali", sono un approccio radicalmente differente alla progettazione dei sistemi operativi. L'idea centrale è "separare la protezione dalla gestione".

Nessuno meglio di uno sviluppatore sa come rendere efficiente l'uso dell'hardware disponibile, quindi l'obiettivo è dargli la possibilità di prendere le decisioni. Gli esokernel sono estremamente piccoli e compatti, poiché le loro funzionalità sono volutamente limitate alla protezione e al multiplexing delle risorse.

I kernel "classici" (sia monolitici che microkernel) astraggono l'hardware, nascondendo le risorse dietro a un ''livello di astrazione dell'hardware''), o dietro a server "sicuri". In questi sistemi "classici", se ad esempio viene allocata della memoria, il programma non può sapere in quale pagina fisica questa verrà riservata dal sistema operativo, e se viene scritto un file non c'è modo di sapere direttamente in quale settore del disco è stato allocato. È questo il livello di astrazione che un esokernel cerca di evitare. Esso permette ad un'applicazione di richiedere aree specifiche di memoria, settori specifici su disco e così via, e si assicura solamente che le risorse richieste siano disponibili e che le applicazioni vi possano accedere.

Dato che un esokernel fornisce un'interfaccia davvero a basso livello all'hardware, mancando di qualsiasi funzionalità di alto livello tipica degli altri sistemi operativi, esso è accompagnato da un ''sistema operativo-libreria'' (in gergo libOS) che si interfaccia con l'esokernel sottostante fornendo quindi agli sviluppatori di applicazioni le funzionalità di un sistema operativo completo.

Tutto ciò ha un'importante implicazione: è possibile avere diversi libOS sul sistema. Se, per esempio, si installa un libOS che esporta un'API Unix e uno che esporta un'API Windows, è possibile eseguire simultaneamente applicazioni compilate per UNIX e per Windows. Lo sviluppo dei libOS avviene a livello utente, senza reboot, debug su console e in piena [[protezione della memoria]].

Al momento gli esokernel sono più che altro dei progetti di ricerca e non sono usati in sistemi operativi commerciali. Un esempio di sistema basato su esokernel è [[Nemesis (informatica)|Nemesis]], sviluppato dall'[[Università di Cambridge]], dall'[[Università di Glasgow]], da [[Citrix Systems]] e dall'[[Istituto reale di tecnologia|Istituto Svedese di Informatica]]. Anche il [[Massachusetts Institute of Technology|MIT]] ha sviluppato diversi sistemi basati su esokernel.

=== EsokernelNo Kernel ===

Il software cosiddetto "no kernel" non ha l'obbligo di essere limitato ad un unico entry point che sia oltretutto centralizzato. Un esempio è dato da progetti come [https://web.archive.org/web/20190602150238/http://tunes.org/ TUNES] e UnununiumOS, che intendevano creare un sistema operativo privo di kernel (entrambi i progetti sono stati interrotti).

Gli esokernel, conosciuti anche come "sistemi operativi verticali", sono un approccio radicalmente differente alla progettazione dei sistemi operativi. L'idea centrale è "separare la protezione dalla gestione".

== Note ==

L'idea che sta dietro è che nessuno sa come rendere efficiente l'uso dell'hardware disponibile meglio di uno sviluppatore, quindi l'obiettivo è dargli la possibilità di prendere le decisioni. Gli esokernel sono estremamente piccoli e compatti, in quanto le loro funzionalità sono arbitrariamente limitate alla protezione e al multiplexing delle risorse.

<references/>

== Bibliografia ==

I kernel "classici" (sia monolitici che microkernel) astraggono l'hardware, nascondendo le risorse dietro a un ''livello di astrazione dell'hardware'' ([[hardware abstraction layer]] o HAL), o dietro a server "sicuri". In questi sistemi "classici" ad esempio, se viene allocata della memoria il programma non può sapere in quale pagina fisica questa verrà riservata dal sistema operativo, e se viene scritto un file non c'è modo di sapere direttamente in quale settore del disco è stato allocato. È questo il livello di astrazione che un esokernel cerca di evitare. Esso permette ad un'applicazione di richiedere aree specifiche di memoria, settori specifici su disco e così via, e si assicura solamente che le risorse richieste siano disponibili e che le applicazioni vi possano accedere.

* {{cita libro |cognome=Deitel |nome=Harvey M. |titolo=An introduction to operating systems |annooriginale=1982 |url=https://portal.acm.org/citation.cfm?id=79046&dl=GUIDE&coll=GUIDE |edizione=revisited first edition |anno=1984 |editore=Addison-Wesley |p=673|isbn=0-201-14502-2 }}

* {{cita pubblicazione|cognome=Denning |nome=Peter J. |linkautore=Peter J. Denning |anno=1980 |mese=aprile|titolo=Why not innovations in computer architecture? |rivista=ACM SIGARCH Computer Architecture News |volume=8 |numero=2 |pp=4-7 |issn=0163-5964 |url=https://portal.acm.org/citation.cfm?id=859506&coll=&dl=ACM&CFID=15151515&CFTOKEN=6184618 }}

* {{cita pubblicazione|cognome=Brinch Hansen |nome=Per |anno=1970 |mese=aprile|titolo=The nucleus of a Multiprogramming System |rivista=Communications of the ACM |volume=13 |numero=4 |pp=238-241 |issn=0001-0782 |url=https://portal.acm.org/citation.cfm?id=362278&dl=ACM&coll=GUIDE&CFID=11111111&CFTOKEN=2222222 }}

* {{cita libro |cognome=Brinch Hansen |nome=Per |wkautore=Per Brinch Hansen |titolo=Operating System Principles |annooriginale=1973 |url=https://portal.acm.org/citation.cfm?id=540365 |editore=Prentice Hall |città=Englewood Cliffs |p=496|isbn=0-13-637843-9 }}

* {{Cita pubblicazione|autore =[[Per Brinch Hansen]]|titolo = The evolution of operating systems|data = 2001|url= http://brinch-hansen.net/papers/2001b.pdf|formato = pdf|accesso = 24 ottobre 2006}} nel libro{{Cita libro | curatore-nome=Per | curatore-cognome=Brinch Hansen | titolo=Classic operating systems: from batch processing to distributed systems | anno=2001 | url=https://portal.acm.org/citation.cfm?id=360596&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618 | editore=Springer-Verlag | città= New York |pp=1-36 | capitolo=1 | urlcapitolo=http://brinch-hansen.net/papers/2001b.pdf | formato=pdf | isbn=0-387-95113-X }}

* {{cita pubblicazione|cognome=Levin |nome=R. |coautori=E. Cohen, W. Corwin, F. Pollack, W. Wulf |anno=1975 |titolo=Policy/mechanism separation in Hydra |rivista=ACM Symposium on Operating Systems Principles / Proceedings of the fifth ACM symposium on Operating systems principles |pp=132-140 |url=https://portal.acm.org/citation.cfm?id=806531&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618 }}

* {{cita pubblicazione|cognome=Linden |nome=Theodore A. |titolo=Operating System Structures to Support Security and Reliable Software | rivista= ACM Computing Surveys (CSUR) |pp=409-445 | volume =8 | numero = 4 | anno=1976| mese=dicembre|issn=0360-0300 | url = https://portal.acm.org/citation.cfm?id=356682&coll=&dl=ACM&CFID=15151515&CFTOKEN=6184618 }}

* {{Cita libro |cognome=Lorin |nome=Harold |titolo=Operating systems |url=https://portal.acm.org/citation.cfm?id=578308&coll=GUIDE&dl=GUIDE&CFID=2651732&CFTOKEN=19681373 |anno=1981 |editore=Addison-Wesley |pp=161-186 |città=Boston, Massachusetts|isbn=0-201-14464-6 }}

* {{cita pubblicazione|cognome=Schroeder |nome=Michael D.|coautori=Jerome H. Saltzer |anno=1972 |mese=marzo|titolo=A hardware architecture for implementing protection rings |rivista=Communications of the ACM |volume=15 |numero=3 |pp=157-170 |issn=0001-0782 |url=https://portal.acm.org/citation.cfm?id=361275&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618 }}

* {{Cita libro |cognome=Shaw |nome=Alan C. |titolo=The logical design of Operating systems |url=https://portal.acm.org/citation.cfm?id=540329 |anno=1974 |editore=Prentice-Hall |p=304|isbn=0-13-540112-7 }}

* {{Cita libro |cognome= Tanenbaum |nome=Andrew S. |wkautore=Andrew S. Tanenbaum |titolo=Structured Computer Organization |anno=1979 |editore=Prentice-Hall |città=Englewood Cliffs, New Jersey |lingua=en|isbn=0-13-148521-0 }}

* {{cita pubblicazione |cognome=Wulf |nome=W. |coautori=E. Cohen, W. Corwin, A. Jones, R. Levin, C. Pierson, F. Pollack |anno=1974 |mese=giugno |titolo=HYDRA: the kernel of a multiprocessor operating system |rivista=Communications of the ACM |volume=17 |numero=6 |pp=337-345 |issn=0001-0782 |url=https://portal.acm.org/citation.cfm?id=36 |urlmorto=sì }}

** {{Cita pubblicazione| titolo = HYDRA:The Kernel of a Multiprocessor Operating System| autore1 = W. Wulf | autore2 = E. Cohen | autore3 = W. Corwin | autore4 = A. Jones | autore5 = R. Levin | autore6 = C. Pierson | autore7 = F. Pollack | lingua = en | url = https://research.cs.wisc.edu/areas/os/Qual/papers/hydra.pdf | formato = pdf | accesso = 12 ottobre 2022 | abstract = sì| urlarchivio = https://web.archive.org/web/20220628141742/https://research.cs.wisc.edu/areas/os/Qual/papers/hydra.pdf | urlmorto = no }}

== Voci correlate ==

Quindi, siccome un esokernel fornisce un'interfaccia davvero a basso livello all'hardware, mancando di qualsiasi funzionalità di alto livello tipica degli altri sistemi operativi, esso è accompagnato da un "sistema operativo-libreria".

* [[Kernel mode]]

Questo "[[libOS]]" si interfaccia all'esokernel sottostante e fornisce agli sviluppatori di applicazioni le funzionalità di un sistema operativo completo.

* [[Schermata blu di errore]]

* [[Kernel panic]]

* [[Spazio utente]]

* [[Linux (kernel)]]

== Altri progetti ==

Tutto ciò ha un'importante implicazione: è possibile avere diversi libOS sul sistema. Se, per esempio, si installa un libOS che esporta un'API Unix e uno che esporta un'API Windows, è possibile eseguire simultaneamente applicazioni compilate per UNIX e per Windows. Lo sviluppo dei libOS avviene a livello utente, senza reboots, debug su console e in piena protezione della memoria.

{{Interprogetto|wikt=kernel|preposizione=sul}}

== Collegamenti esterni ==

Al momento gli esokernel sono più che altro dei progetti di ricerca e non sono usati in sistemi operativi commerciali. Un esempio di sistema basato su esokernel è [[Nemesis (informatica)|Nemesis]], sviluppato dall'[[Università di Cambridge]], dall'[[Università di Glasgow]], da [[Citrix Systems]] e dall'[[Istituto Svedese di Informatica]]. Anche il [[MIT]] ha sviluppato diversi sistemi basati su esokernel.

* {{Collegamenti esterni}}

* {{FOLDOC}}

{{Componenti di Windows}}

[[Categoria:Software]]

{{Controllo di autorità}}

{{Portale|informatica}}

[[enCategoria:Kernel| ]]

[[de:Kernel]]

[[es:Kernel]]

[[ja:&#12459;&#12540;&#12493;&#12523;]][[nl:Kernel]]

[[pl:J&#261;dro systemu operacyjnego]]

[[fr:Noyau_(informatique)]]

[[sv:Operativsystemskärna]]