\label{fig:intro_sys_struct}
\end{figure}
-Normalmente ciascuna di queste chiamate al sistema viene rimappata in
-opportune funzioni con lo stesso nome definite dentro la Libreria Standard del
-C, che, oltre alle interfacce alle system call, contiene anche tutta la serie
-delle ulteriori funzioni definite dai vari standard, che sono comunemente
-usate nella programmazione.
+Normalmente ciascuna di queste chiamate al sistema fornite dal kernel viene
+rimappata in opportune funzioni con lo stesso nome definite dentro la Libreria
+Standard del C, che, oltre alle interfacce alle \textit{system call}, contiene
+anche tutta la serie delle ulteriori funzioni definite dai vari standard, che
+sono comunemente usate nella programmazione.
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
operazioni comuni come l'allocazione dinamica della memoria, l'input/output
-bufferizzato o la manipolazione delle stringhe, presenti in qualunque
+bufferizzato sui file o la manipolazione delle stringhe, presenti in qualunque
programma.
Quanto appena illustrato mette in evidenza il fatto che nella stragrande
rimpiazzo delle \acr{glibc} in tutti quei sistemi specializzati che
richiedono una minima occupazione di memoria.} si dovrebbe usare il nome
GNU/Linux (piuttosto che soltanto Linux) in quanto una parte essenziale del
-sistema (senza la quale niente funzionerebbe) è la GNU Standard C Library (in
-breve \acr{glibc}), ovvero la libreria realizzata dalla Free Software
-Foundation nella quale sono state implementate tutte le funzioni essenziali
-definite negli standard POSIX e ANSI C, utilizzabili da qualunque programma.
+sistema (senza la quale niente funzionerebbe) è la \textit{GNU Standard C
+ Library} (in breve \acr{glibc}), ovvero la libreria realizzata dalla Free
+Software Foundation nella quale sono state implementate tutte le funzioni
+essenziali definite negli standard POSIX e ANSI C, utilizzate da qualunque
+programma.
Le funzioni di questa libreria sono quelle riportate dalla terza sezione del
\textsl{Manuale di Programmazione di Unix} (cioè accessibili con il comando
programmi, non si hanno differenze pratiche fra l'uso di una funzione di
libreria e quello di una chiamata al sistema.
+Le librerie standard del C consentono comunque, nel caso non sia presente una
+specifica funzione di libreria corrispondente, di eseguire una \textit{system
+ call} generica tramite la funzione \funcd{syscall}, il cui prototipo,
+accessible se si è definita la macro \macro{\_GNU\_SOURCE}, (vedi
+sez.~\ref{sec:intro_gcc_glibc_std}) è:
+\begin{functions}
+ \headdecl{unistd.h}
+ \headdecl{sys/syscall.h}
+ \funcdecl{int syscall(int number, ...)}
+
+ Esegue la \textit{system call} indicata da \param{number}.
+\end{functions}
+
+La funzione richiede come primo argomento il numero della \textit{system call}
+da invocare, seguita dagli argomenti da passare alla stessa (che ovviamente
+dipendono da quest'ultima), e restituisce il codice di ritorno della
+\textit{system call} invocata. In generale un valore nullo indica il successo
+ed un valore negativo è un codice di errore che poi viene memorizzato nella
+variabile \var{errno} (sulla gestione degli errori torneremo in dettaglio in
+sez.~\ref{sec:sys_errors}).
+
+Il valore di \param{number} dipende sia dalla versione di kernel che
+dall'architettura,\footnote{in genere le vecchie \textit{system call} non
+ vengono eliminate e se ne aggiungono di nuove con nuovi numeri.} ma
+ciascuna \textit{system call} viene in genere identificata da una costante
+nella forma \texttt{SYS\_*} dove al prefisso viene aggiunto il nome che spesso
+corrisponde anche alla omonima funzione di libreria; queste costanti sono
+definite nel file \texttt{sys/syscall.h}, ma si possono anche usare
+direttamente valori numerici.
+
\subsection{Un sistema multiutente}
\label{sec:intro_multiuser}
Linux, come gli altri kernel Unix, nasce fin dall'inizio come sistema
multiutente, cioè in grado di fare lavorare più persone in contemporanea. Per
questo esistono una serie di meccanismi di sicurezza, che non sono previsti in
-sistemi operativi monoutente, e che occorre tenere presente.
+sistemi operativi monoutente, e che occorre tenere presenti.
Il concetto base è quello di utente (\textit{user}) del sistema, le cui
capacità rispetto a quello che può fare sono sottoposte a ben precisi limiti.
Sono così previsti una serie di meccanismi per identificare i singoli utenti
ed una serie di permessi e protezioni per impedire che utenti diversi possano
-danneggiarsi a vicenda o danneggiare il sistema.
+danneggiarsi a vicenda o danneggiare il sistema. Questi meccanismi sono
+realizzati dal kernel stesso ed attengono alle operazioni più varie, e
+torneremo su di essi in dettaglio più avanti.
Ogni utente è identificato da un nome (l'\textit{username}), che è quello che
viene richiesto all'ingresso nel sistema dalla procedura di \textit{login}
possibili meccanismi diversi.\footnote{ad esempio usando la libreria PAM
(\textit{Pluggable Autentication Methods}) è possibile astrarre
completamente dai meccanismi di autenticazione e sostituire ad esempio l'uso
- delle password con meccanismi di identificazione biometrica.}
-
-Eseguita la procedura di riconoscimento in genere il sistema manda in
-esecuzione un programma di interfaccia (che può essere la \textit{shell} su
-terminale o un'interfaccia grafica) che mette a disposizione dell'utente un
-meccanismo con cui questo può impartire comandi o eseguire altri programmi.
+ delle password con meccanismi di identificazione biometrica.} Eseguita la
+procedura di riconoscimento in genere il sistema manda in esecuzione un
+programma di interfaccia (che può essere la \textit{shell} su terminale o
+un'interfaccia grafica) che mette a disposizione dell'utente un meccanismo con
+cui questo può impartire comandi o eseguire altri programmi.
Ogni utente appartiene anche ad almeno un gruppo (il cosiddetto
\textit{default group}), ma può essere associato ad altri gruppi (i
\textit{supplementary group}), questo permette di gestire i permessi di
accesso ai file e quindi anche alle periferiche, in maniera più flessibile,
-definendo gruppi di lavoro, di accesso a determinate risorse, ecc.
+definendo gruppi di lavoro, di accesso a determinate risorse, ecc.
L'utente e il gruppo sono identificati da due numeri, la cui corrispondenza ad
un nome espresso in caratteri è inserita nei due file \conffile{/etc/passwd} e
\textsl{user-ID}, ed indicato dall'acronimo \acr{uid}, e il \textit{group
identifier}, detto in breve \textsl{group-ID}, ed identificato dall'acronimo
\acr{gid}, e sono quelli che vengono usati dal kernel per identificare
-l'utente.
+l'utente; torneremo in dettaglio su questo argomento in
+sez.~\ref{sec:proc_perms}.
In questo modo il sistema è in grado di tenere traccia dell'utente a cui
appartiene ciascun processo ed impedire ad altri utenti di interferire con
per le prestazioni, è quella dell'accesso a disco. Per questo motivo sono
stati introdotti diversi \textit{I/O scheduler} in grado di distribuire in
maniera opportuna questa risorsa ai vari processi. Fino al kernel 2.6.17 era
-possibile soltanto decidere le politiche di gestione scegliendo un diverso
-\textit{I/O scheduler}
-
+possibile soltanto differenziare le politiche generali di gestione, scegliendo
+di usare un diverso \textit{I/O scheduler}; a partire da questa versione, con
+l'introduzione dello scheduler CFQ (\textit{Completely Fair Queuing}) è
+divenuto possibile, qualora si usi questo scheduler, impostare anche delle
+diverse priorità di accesso per i singoli processi.\footnote{al momento
+ (kernel 2.6.31), le priorità di I/O sono disponibili soltanto per questo
+ scheduler.}
+
+La scelta dello scheduler di I/O si può fare in maniera generica a livello di
+avvio del kernel assegnando il nome dello stesso al parametro
+\texttt{elevator}, mentre se ne può indicare uno per l'accesso al singolo
+disco scrivendo nel file \texttt{/sys/block/\textit{dev}/queue/scheduler}
+(dove \texttt{\textit{dev}} è il nome del dispositivo associato al disco); gli
+scheduler disponibili sono mostrati dal contenuto dello stesso file che
+riporta fra parentesi quadre quello attivo, il default in tutti i kernel
+recenti è proprio il \texttt{cfq},\footnote{nome con cui si indica appunto lo
+ scheduler \textit{Completely Fair Queuing}.} che supporta le priorità; per i
+dettagli sulle caratteristiche specifiche degli altri scheduler, la cui
+discussione attiene a problematiche di ambito sistemistico, si consulti la
+documentazione nella directory \texttt{Documentation/block/} dei sorgenti del
+kernel.
+
+Una volta che si sia impostato lo scheduler CFQ ci sono due specifiche system
+call, specifiche di Linux, che consentono di leggere ed impostare le priorità
+di I/O.\footnote{se usate in corrisponenza ad uno scheduler diverso il loro
+ utilizzo non avrà alcun effetto.} Dato che non esiste una interfaccia
+diretta nelle librerie del C per queste due funzioni occorrerà invocarle
+tramite la funzione \func{syscall} (come illustrato in
+sez.~\ref{sec:intro_syscall}).
+
+Lo scheduler CFQ prevede la presenza di tre diverse classi, e ricalcando i
+concetti dello scheduler della CPU,
%TODO trattare le priorità di I/O
% vedi man ioprio_set e Documentation/block/ioprio.txt
projects / gapil.git / commitdiff