Corso di Sistemi Operativi

Chiamate di sistema e interprete dei comandi

 

La volta scorsa abbiamo visto che per realizzare un accesso protetto a certe funzioni del sistema (come l’I/O), vengono usate delle istruzioni privilegiate che, in quanto tali, possono essere eseguite solamente dal kernel del SO.
Quando i programmi utente necessitano di adoperare queste funzionalità, possono richiedere al SO di eseguirle per proprio conto, invocando delle chiamate di sistema (system calls).

Le system calls costituiscono l’interfaccia tra il SO e i programmi utente, una sorta di «istruzioni estese» con le quali i programmi utente possono comunicare con il SO e richiedergli dei servizi.
Ad ogni chiamata di sistema corrisponde una procedura di libreria, che il programma utente può chiamare specificando gli opportuni parametri.
La procedura invoca un’istruzione trap (una sorta di procedura protetta) per far partire il SO.
L’obiettivo della procedura di libreria è quello di nascondere i dettagli dell’istruzione trap e di rendere le chiamate di sistema simili alle normali chiamate di procedura.

L’insieme di tutte le procedure di libreria corrispondenti a chiamate di sistema prende il nome di API (Application Programming Interface).
Solitamente il numero e il tipo di tali chiamate varia a seconda del SO e riguardano l’input/output e la gestione della memoria e dei processi.

Oltre che per mezzo delle system calls, l’interazione tra l’utente e il sistema può avvenire anche tramite un linguaggio di comandi interpretato da uno speciale programma di sistema, detto interprete dei comandi o shell.
Il nome “shell” (che significa guscio) è giustificato dal fatto che essa è l'involucro con cui l’utente entra in contatto quando vuole interagire con il sistema sottostante (il termine kernel significa nocciolo, nucleo).
Quando un utente si collega al sistema viene avviata la shell, che stampa sul video un prompt (invito) per indicare che è in attesa di un comando (come avviene nelle shell testuali di UNIX e MS-DOS) o che inizializza un ambiente grafico pronto a interagire con sistemi di puntamento, come i mouse (è il caso delle interfacce grafiche di sistemi come Mac OS, Windows, BeOS, QNX).

Quando una shell attende ed esegue i comandi impartiti dall’utente, si trova in una modalità di funzionamento interattivo e mostra, per lo più, simboli e informazioni utili all’utente per tenere d’occhio il contesto in cui sta operando (soprattutto nel caso di shell testuali).
Quando l’utente batte il comando, ad es. il nome di un file eseguibile seguito dalle sue opzioni, la shell si incarica di intraprendere tutte le operazioni necessarie ad avviare il processo corrispondente, comprese le eventuali invocazioni di chiamate di sistema.

Oltre a file eseguibili, la shell riconosce anche dei comandi propri, detti built-in, che offrono all’utente delle caratteristiche aggiuntive, come la possibilità di creare cicli di istruzioni, stampare messaggi a video e altro ancora.
I comandi built-in possono sono spesso utilizzati all’interno di file particolari, detti script di shell, costituiti da arbitrarie sequenze di comandi e istruzioni, che vengono eseguiti sequenzialmente per automatizzare molte operazioni.
Un esempio molto noto è rappresentato dai file batch (con estensione .bat) di MS-DOS.

Le shell hanno caratteristiche dipendenti dal sistema e possono fornire servizi utili aggiuntivi.
Tra questi, una proprietà molto apprezzata delle shell testuali è lo storico dei comandi, ossia un registro contenente gli ultimi comandi inseriti dall’utente.
Quando la shell lo gestisce, l’utente può facilmente ripescare, ed eventualmente modificare, un comando utilizzato poco prima senza doverlo riscrivere completamente.

Alcuni sistemi implementano le shell non come programmi esterni al SO (anche se fortemente interagenti con esso), ma come parte del kernel stesso: in questi casi il termine shell è meno significativo, ma altrettanto usato.
Nella prossima puntata vedremo le varie fasi che permettono, ad un programma scritto in un linguaggio di programmazione ad alto livello, di diventare un processo del SO.

 

Torna all'indice Generale del corso di Corso di Sistemi Operativi di Software Planet