(e non possono accedere direttamente alle zone di memoria riservate o alle
porte di input/output).
-Una parte del kernel, lo \textit{scheduler}\itindex{scheduler}, si occupa di
+Una parte del kernel, lo \itindex{scheduler} \textit{scheduler}, si occupa di
stabilire, ad intervalli fissi e sulla base di un opportuno calcolo delle
priorità, quale ``\textsl{processo}'' deve essere posto in esecuzione (il
-cosiddetto \textit{prehemptive
- multitasking}\itindex{prehemptive~multitasking}). Questo verrà comunque
-eseguito in modalità protetta; quando necessario il processo potrà accedere
-alle risorse hardware soltanto attraverso delle opportune chiamate al sistema
-che restituiranno il controllo al kernel.
+cosiddetto \itindex{prehemptive~multitasking} \textit{prehemptive
+ multitasking}). Questo verrà comunque eseguito in modalità protetta; quando
+necessario il processo potrà accedere alle risorse hardware soltanto
+attraverso delle opportune chiamate al sistema che restituiranno il controllo
+al kernel.
La memoria viene sempre gestita dal kernel attraverso il meccanismo della
\textsl{memoria virtuale}\index{memoria~virtuale}, che consente di assegnare a
un'espressione gergale che significa ``sollevarsi da terra tirandosi per le
stringhe delle scarpe'', per indicare il compito, almeno apparentemente
impossibile, di far eseguire un programma a partire da un computer appena
- acceso che appunto non ne contiene nessuno; non è impossibile appunto perché
- in realtà c'è un programma iniziale, che è appunto il BIOS.}), incaricandosi
-di caricare il kernel in memoria e di farne partire l'esecuzione;
-quest'ultimo, dopo aver inizializzato le periferiche, farà partire il primo
-processo, \cmd{init}, che è quello che a sua volta farà partire tutti i
-processi successivi. Fra questi ci sarà pure quello che si occupa di dialogare
-con la tastiera e lo schermo della console, e quello che mette a disposizione
+ acceso che appunto non ne contiene nessuno; non è impossibile perché in
+ realtà c'è un programma iniziale, che è il BIOS.}), incaricandosi di
+caricare il kernel in memoria e di farne partire l'esecuzione; quest'ultimo,
+dopo aver inizializzato le periferiche, farà partire il primo processo,
+\cmd{init}, che è quello che a sua volta farà partire tutti i processi
+successivi. Fra questi ci sarà pure quello che si occupa di dialogare con la
+tastiera e lo schermo della console, e quello che mette a disposizione
dell'utente che si vuole collegare, un terminale e la \textit{shell} da cui
inviare i comandi.
Questo è importante da capire perché programmare in Linux significa anzitutto
essere in grado di usare le varie interfacce contenute nella Libreria Standard
-del C, in quanto né il kernel, né il linguaggio C, implementano direttamente
+del C, in quanto né il kernel, né il linguaggio C implementano direttamente
operazioni comuni come l'allocazione dinamica della memoria, l'input/output
bufferizzato o la manipolazione delle stringhe, presenti in qualunque
programma.
\label{sec:intro_bsd}
Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l'Università
-di Berkley e la AT\&T generò una delle prime e più importanti fratture del
+di Berkeley e la AT\&T generò una delle prime e più importanti fratture del
mondo Unix. L'Università di Berkley proseguì nello sviluppo della base di
codice di cui disponeva, e che presentava parecchie migliorie rispetto alle
versioni allora disponibili, fino ad arrivare al rilascio di una versione
della AT\&T.
Benché BSD non sia uno standard formalizzato, l'implementazione di Unix
-dell'Università di Berkley, ha provveduto nel tempo una serie di estensioni e
+dell'Università di Berkeley, ha provveduto nel tempo una serie di estensioni e
API di grande rilievo, come i link simbolici, la funzione \code{select} ed i
socket.
projects / gapil.git / commitdiff