Aggiunta spiegazione sui file di dispositivo, figura sui terminali.
[gapil.git] / session.tex
index ffc69467efca3794e40114eda8a0b65bd595ee1a..10129fa70b7f24995a3b0262ce3ed71e126a2520 100644 (file)
@@ -1,13 +1,18 @@
- \chapter{Sessioni di lavoro e terminali}
+\chapter{Terminali e sessioni di lavoro}
 \label{cha:session}
 
 \label{cha:session}
 
-Esamineremo in questo capitolo i concetti base del sistema delle sessioni di
-lavoro, vale a dire il metodo con cui il kernel gestisce l'accesso concorrente
-al sistema da parte di più utenti, permettendo loro di eseguire più programmi
-in contemporanea.  Nella seconda parte del capitolo tratteremo poi il
-funzionamento dell'I/O su terminale, e delle varie peculiarità che esso viene
-ad assumere a causa del suo stretto legame con le modalità di accesso al
-sistema da parte degli utenti.
+I terminali per lungo tempo tempo sono stati l'unico modo per accedere al
+sistema, per questo anche oggi che esistono molte altre interfacce, essi
+continuano a coprire un ruolo particolare, restando strettamente legati al
+funzionamento dell'interfaccia a linea di comando.
+
+Mella prima parte del capitolo esamineremo i concetti base del sistema delle
+sessioni di lavoro, vale a dire il metodo con cui il kernel permette ad un
+utente di gestire le capacità multitiasking del sistema, permettendo di
+eseguire più programmi in contemporanea.  Nella seconda parte del capitolo
+tratteremo poi il funzionamento dell'I/O su terminale, e delle varie
+peculiarità che esso viene ad assumere a causa del suo stretto legame con il
+suo uso come interfaccia di accesso al sistema da parte degli utenti.
 
 
 \section{Il \textit{job control}}
 
 
 \section{Il \textit{job control}}
@@ -490,11 +495,7 @@ Un terminale, che esso sia un terminale effettivo, attaccato ad una seriale o
 ad un altro tipo di porta di comunicazione, o una delle console virtuali
 associate allo schermo, viene sempre visto attraverso attraverso un device
 driver che ne presenta un'interfaccia comune su un apposito file di
 ad un altro tipo di porta di comunicazione, o una delle console virtuali
 associate allo schermo, viene sempre visto attraverso attraverso un device
 driver che ne presenta un'interfaccia comune su un apposito file di
-dispositivo. Storicamente i primi terminali erano appunto terminali di
-telescriventi (\textit{teletype}), da cui deriva sia il nome dell'interfaccia,
-\textit{tty}, che quello dei relativi file di dispositivo, che sono sempre
-della forma \texttt{/dev/tty*}.\footnote{questo vale anche per i terminali
-  virtuali associati alle connessioni di rete con \cmd{telnet} o \cmd{ssh}.}
+dispositivo.
 
 Per controllare un terminale si usa di solito il programma \cmd{getty} (od una
 delle sue varianti), che permette di mettersi in ascolto su uno di questi
 
 Per controllare un terminale si usa di solito il programma \cmd{getty} (od una
 delle sue varianti), che permette di mettersi in ascolto su uno di questi
@@ -602,26 +603,31 @@ occorrer
 \begin{enumerate}
 \item Eseguire una \func{fork} e terminare immediatamente il processo padre
   proseguendo l'esecuzione nel figlio.  In questo modo si ha la certezza che
 \begin{enumerate}
 \item Eseguire una \func{fork} e terminare immediatamente il processo padre
   proseguendo l'esecuzione nel figlio.  In questo modo si ha la certezza che
-  il processo non è un \textit{process group leader}, e si può chiamare
-  \func{setsid} con successo.
+  il figlio non è un \textit{process group leader}, (avrà il \acr{pgid} del
+  padre, ma un \acr{pid} diverso) e si può chiamare \func{setsid} con
+  successo. Inoltre la shell considererà terminato il comando all'uscita del
+  padre.
 \item Eseguire \func{setsid} per creare una nuova sessione ed un nuovo
 \item Eseguire \func{setsid} per creare una nuova sessione ed un nuovo
-  raggruppamento di cui il processo è leader, che non ha associato nessun
-  terminale di controllo.
+  raggruppamento di cui il processo diventa automaticamente il leader, che
+  però non ha associato nessun terminale di controllo.
 \item Assicurarsi che al processo non venga associato in seguito nessun nuovo
   terminale di controllo; questo può essere fatto sia avendo cura di usare
   sempre l'opzione \macro{O\_NOCTTY} nell'aprire i file di terminale, che
 \item Assicurarsi che al processo non venga associato in seguito nessun nuovo
   terminale di controllo; questo può essere fatto sia avendo cura di usare
   sempre l'opzione \macro{O\_NOCTTY} nell'aprire i file di terminale, che
-  eseguendo una ulteriore \func{fork} proseguendo nel figlio, che a questo
-  punto non essendo più leader di sessione  non può più ottenere un terminale
-  di controllo.
-\item Eseguire una \func{chdir} per impostare la directory di lavoro (su
-  \file{/} o su una directory che contenga dei file necessari per il
-  programma), per evitare che la directory da cui si è lanciato il processo
+  eseguendo una ulteriore \func{fork} uscendo nel padre e proseguendo nel
+  figlio. In questo caso, non essendo più quest'ultimo un leader di sessione
+  non potrà ottenere automaticamente un terminale di controllo.
+\item Eseguire una \func{chdir} per impostare la directory di lavoro del
+  processo (su \file{/} o su una directory che contenga dei file necessari per
+  il programma), per evitare che la directory da cui si è lanciato il processo
   resti in uso e non sia possibile rimuoverla o smontare il filesystem che la
   contiene.
 \item Impostare la maschera dei permessi (di solito con \code{umask(0)}) in
   modo da non essere dipendenti dal valore ereditato da chi ha lanciato
   originariamente il processo. 
   resti in uso e non sia possibile rimuoverla o smontare il filesystem che la
   contiene.
 \item Impostare la maschera dei permessi (di solito con \code{umask(0)}) in
   modo da non essere dipendenti dal valore ereditato da chi ha lanciato
   originariamente il processo. 
-\item Chiudere i file standard (o redirigerli verso \file{/dev/null}).
+\item Chiudere tutti i file aperti che non servono più (in generale tutti); in
+  particolare vanno chiusi i file standard che di norma sono ancora associati
+  al terminale (un'altra opzione è quella di redirigerli verso
+  \file{/dev/null}).
 \end{enumerate}
 
 
 \end{enumerate}
 
 
@@ -637,22 +643,357 @@ prototipo 
     valori impostati dalle sottostanti \func{fork} e \func{setsid}.}
 \end{prototype}
 
     valori impostati dalle sottostanti \func{fork} e \func{setsid}.}
 \end{prototype}
 
-La funzione esegue una \func{fork}, per uscire subito, con \func{\_exit} nel
-padre, mentre l'esecuzione prosegue nel figlio che esegue \func{setsid}. Se
-\param{nochdir} è nullo la funzione imposta anche la directory di lavoro su
-\file{/}, se \param{noclose} è nullo i file standard vengono rediretti su
-\file{dev/null}; in caso di valori non nulli non viene eseguita nessuna altra
-azione.
+La funzione esegue una \func{fork}, per uscire subito, con \func{\_exit}, nel
+padre, mentre l'esecuzione prosegue nel figlio che esegue subito una
+\func{setsid}. In questo modo si compiono automaticamente i passi 1 e 2 della
+precedente lista. Se \param{nochdir} è nullo la funzione imposta anche la
+directory di lavoro su \file{/}, se \param{noclose} è nullo i file standard
+vengono rediretti su \file{/dev/null} (corrispondenti ai passi 4 e 6); in caso
+di valori non nulli non viene eseguita nessuna altra azione.
+
+Dato che un programma demone non può più accedere al terminale, si pone il
+problema di come fare per la notifica di eventuali errori, non potendosi più
+utilizzare lo standard error; per il normale I/O infatti ciascun demone avrà
+le sue modalità di interazione col sistema e gli utenti a seconda dei compiti
+e delle funzionalità che sono sono previste; ma gli errori devono normalmente
+essere notificati all'amministratore del sistema.
+
+Una soluzione può essere quella di scrivere gli eventuali messaggi su uno
+specifico file (cosa che a volte viene fatta comunque) ma questo comporta il
+grande svantaggio che l'amministratore dovrà tenere sotto controllo un file
+diverso per ciascun demone, e che possono anche generarsi conflitti di nomi.
+Per questo in BSD4.2 venne introdotto un servizio di sistema, il
+\textit{syslog}, che oggi si trova su tutti i sistemi Unix, e che permettesse
+ai demoni di inviare messaggi all'amministratore in una maniera
+standardizzata.
+
+Il servizio prevede vari meccanismi di notifica, e, come ogni altro servizio
+in un sistema unix-like, viene gestito attraverso un apposito programma,
+\cmd{syslogd}, che è anch'esso un \textsl{demone}. In generale i messaggi di
+errore vengono raccolti dal file speciale \file{/dev/log}, un \textit{socket}
+locale (vedi \secref{sec:sock_sa_local}) dedicato a questo scopo, o via rete,
+con un \textit{socket} UDP, o da un apposito demone, \cmd{klogd}, che estrae i
+messaggi del kernel.\footnote{i messaggi del kernel sono tenuti in un buffer
+  circolare e scritti tramite la funzione \func{printk}, analoga alla
+  \func{printf} usata in user space; una trattazione eccellente dell'argomento
+  si trova in \cite{LinDevDri}, nel quarto capitolo.}
+
+Il servizio permette poi di trattare i vari messaggi classificandoli
+attraverso due indici; il primo, chiamato \textit{facility}, suddivide in
+diverse categorie i vari demoni in modo di raggruppare i messaggi provenienti
+da operazioni che hanno attinenza fra loro, ed è organizzato in sottosistemi
+(kernel, posta elettronica, demoni di stampa, ecc.). Il secondo, chiamato
+\textit{priority}, identifica l'importanza dei vari messaggi, e permette di
+classificarli e differenziare le modalità di notifica degli stessi.
+
+Il sistema di \textit{syslog} attraverso \cmd{syslogd} provvede poi a
+riportare i messaggi all'amministratore attraverso una serie differenti
+meccanismi come:
+\begin{itemize*}
+\item scrivere sulla console.
+\item inviare via mail ad uno specifico utente.
+\item scrivere su un file (comunemente detto \textit{log file}).
+\item inviare ad un altro demone (anche via rete).
+\item scartare.
+\end{itemize*}
+secondo le modalità che questo preferisce e che possono essere impostate
+attraverso il file di configurazione \file{/etc/syslog.conf} (maggiori
+dettagli si possono trovare sulle pagine di manuale per questo file e per
+\cmd{syslogd}).
+
+Le \acr{glibc} definiscono una serie di funzioni standard con cui un processo
+può accedere in maniera generica al servizio di \textit{syslog}, che però
+funzionano solo localmente; se si vogliono inviare i messaggi ad un'altro
+sistema occorre farlo esplicitamente con un socket UDP, o utilizzare le
+capacità di reinvio del servizio.
+
+La prima funzione definita dall'interfaccia è \func{openlog}, che apre una
+connessione al servizio di \textit{syslog}; essa in generale non è necessaria
+per l'uso del servizio, ma permette di impostare alcuni valori che controllano
+gli effetti delle chiamate successive; il suo prototipo è:
+\begin{prototype}{syslog.h}{void openlog(const char *ident, int option, 
+int facility)}
+
+Apre una connessione al sistema di \textit{syslog}.
+  
+\bodydesc{La funzione non restituisce nulla.}
+\end{prototype}
 
 
+La funzione permette di specificare, tramite \param{ident}, l'identità di chi
+ha inviato il messaggio (di norma si passa il nome del programma, come
+specificato da \code{argv[0]}); la stringa verrà preposta all'inizio di ogni
+messaggio. Si tenga presente che il valore di \param{ident} che si passa alla
+funzione è un puntatore, se la stringa cui punta viene cambiata lo sarà pure
+nei successivi messaggi, e se viene cancellata i risultati potranno essere
+impredicibili, per questo è sempre opportuno usare una stringa costante. 
+
+L'argomento \param{facility} permette invece di preimpostare per le successive
+chiamate l'omonimo indice che classifica la categoria del messaggio.
+L'argomento è interpretato come una maschera binaria, e pertanto è possibile
+inviare i messaggi su più categorie alla volta; i valori delle costanti che
+identificano ciascuna categoria sono riportati in
+\tabref{tab:sess_syslog_facility}, il valore di \param{facility} deve essere
+specificato con un OR aritmetico.
+
+\begin{table}[htb]
+  \footnotesize
+  \centering
+  \begin{tabular}[c]{|l|p{8cm}|}
+    \hline
+    \textbf{Valore}& \textbf{Significato}\\
+    \hline
+    \hline
+    \macro{LOG\_AUTH}     & Messaggi relativi ad autenticazione e sicurezza,
+                            obsoleto, è sostituito da \macro{LOG\_AUTHPRIV}. \\
+    \macro{LOG\_AUTHPRIV} & Sostituisce \macro{LOG\_AUTH}.\\
+    \macro{LOG\_CRON}     & Messaggi dei demoni di gestione dei comandi
+                            programmati (\cmd{cron} e \cmd{at}).\\
+    \macro{LOG\_DAEMON}   & Demoni di sistema.\\
+    \macro{LOG\_FTP}      & Server FTP.\\
+    \macro{LOG\_KERN}     & Messaggi del kernel\\
+    \macro{LOG\_LOCAL0}   & Riservato all'amministratore per uso locale\\
+    --- & \\
+    \macro{LOG\_LOCAL7}   & Riservato all'amministratore per uso locale\\
+    \macro{LOG\_LPR}      & Messaggi del sistema di gestione delle stampanti \\
+    \macro{LOG\_MAIL}     & Messaggi del sistema di posta elettronica\\
+    \macro{LOG\_NEWS}     & Messaggi del sistema di gestione delle news 
+                            (USENET) \\
+    \macro{LOG\_SYSLOG}   & Messaggi generati dallo stesso \cmd{syslogd}\\
+    \macro{LOG\_USER}     & Messaggi generici a livello utente\\
+    \macro{LOG\_UUCP}     & Messaggi del sistema UUCP\\
+\hline
+\end{tabular}
+\caption{Valori possibili per l'argomento \param{facility} di \func{openlog}.}
+\label{tab:sess_syslog_facility}
+\end{table}
+
+L'argomento \param{option} serve invece per controllare il comportamento della
+funzione \func{openlog} e delle modalità con cui le successive chiamate
+scriveranno i messaggi, esso viene specificato come maschera binaria composta
+con un OR aritmetico di una qualunque delle costanti riportate in
+\tabref{tab:sess_openlog_option}.
+
+\begin{table}[htb]
+  \footnotesize
+\centering
+\begin{tabular}[c]{|l|p{8cm}|}
+\hline
+\textbf{Valore}& \textbf{Significato}\\
+\hline
+\hline
+\macro{LOG\_CONS}   & Scrive sulla console quando. \\
+\macro{LOG\_NDELAY} & Sostituisce \macro{LOG\_AUTH}.\\
+\macro{LOG\_NOWAIT} & Messaggi dei demoni di gestione dei comandi
+                      programmati (\cmd{cron} e \cmd{at}).\\
+\macro{LOG\_ODELAY} & .\\
+\macro{LOG\_PERROR} & Stampa anche su \file{stderr}.\\
+\macro{LOG\_PID}    & Inserisce nei messaggi il \acr{pid} del processo
+                      chiamante. \\
+\hline
+\end{tabular}
+\caption{Valori possibili per l'argomento \param{option} di \func{openlog}.}
+\label{tab:sess_openlog_option}
+\end{table}
+
+La funzione che si usa per generare un messaggio è \func{syslog}, dato che
+l'uso di \func{openlog} è ozionale, sarà quest'ultima a provvede a chiamare la
+prima qualora ciò non sia stato fatto (nel qual caso il valore di
+\param{ident} è nullo). Il suo prototipo è:
+\begin{prototype}{syslog.h}
+{void syslog(int priority, const char *format, ...)}
+
+Genera un messaggio di priorità \param{priority}.
+
+\bodydesc{La funzione non restituisce nulla.}
+\end{prototype}
+
+Il comportamento della funzione è analogo quello di \func{printf}, e il valore
+dell'argomento \param{format} è identico a quello descritto nella pagina di
+manuale di quest'ultima (per i valori principali si può vedere la trattazione
+sommaria che se ne è fatto in \secref{sec:file_formatted_io}); l'unica
+differenza è che la sequenza \cmd{\%m} viene rimpiazzata dalla stringa
+restituita da \code{strerror(errno)}. Gli argomenti seguenti i primi due
+devono essere forniti secondo quanto richiesto da \func{format}.
+
+L'argomento \param{priority} permette di impostare sia la \textit{facility}
+che la \textit{priority} del messaggio. In realtà viene prevalentemente usato
+per specificare solo quest'ultima in quanto la prima viene di norma
+preimpostata con \func{openlog}. La priorità è indicata con un valore
+numerico\footnote{le \acr{glibc}, seguendo POSIX.1-2001, prevedono otto
+  diverse priorità ordinate da 0 a 7, in ordine di importanza decrescente;
+  questo comporta che i tre bit meno significativi dell'argomento
+  \param{priority} sono occupati da questo valore, mentre i restanti bit più
+  significativi vengono usati per specificare la \textit{facility}.}
+specificabile attraverso le costanti riportate in
+\secref{tab:sess_syslog_priority}.  Nel caso si voglia specificare anche la
+\textit{facility} basta eseguire un OR aritmetico del valore della priorità
+con la maschera binaria delle costanti di \tabref{tab:sess_syslog_facility}.
+
+\begin{table}[htb]
+  \footnotesize
+  \centering
+  \begin{tabular}[c]{|l|p{8cm}|}
+    \hline
+    \textbf{Valore}& \textbf{Significato}\\
+    \hline
+    \hline
+    \macro{LOG\_EMERG}   & Il sistema è inutilizzabile. \\
+    \macro{LOG\_ALERT}   & C'è una emergenza che richiede intervento
+                           immediato.\\
+    \macro{LOG\_CRIT}    & Si è in una condizione critica.\\
+    \macro{LOG\_ERR}     & Si è in una condizione di errore.\\
+    \macro{LOG\_WARNING} & Messaggio di avvertimento.\\
+    \macro{LOG\_NOTICE}  & Notizia significativa relativa al comportamento.\\
+    \macro{LOG\_INFO}    & Messaggio informativo. \\
+    \macro{LOG\_DEBUG}   & Messaggio di debug.\\
+    \hline
+  \end{tabular}
+  \caption{Valori possibili per l'indice di importanza del messaggio da
+    specificare nell'argomento \param{priority} di \func{syslog}.}
+  \label{tab:sess_syslog_priority}
+\end{table}
+
+Una ulteriore funzione, \func{setlogmask}, permette di filtrare
+preliminarmente i messaggi in base alla loro priorità; il suo prototipo è:
+\begin{prototype}{syslog.h}
+{int setlogmask(int mask)}
+
+Imposta la maschera dei log al valore specificato.
+
+\bodydesc{La funzione restituisce il precedente valore.}
+\end{prototype}
+
+Le routine di gestione mantengono per ogni processo una maschera che
+determina quale delle chiamate effettuate a \func{syslog} verrà
+effettivamente registrata. La registrazione viene disabilitata per tutte
+quelle priorità che non rientrano nella maschera; questa viene settata
+usando la macro \code{LOG\_MASK(p)} dove \code{p} è una delle costanti di
+\secref{tab:sess_syslog_priority}. É inoltre disponibile anche la macro
+\code{LOG\_UPTO(p)} che permette di specificare automaticamente tutte le
+priorità fino ad un certo valore.
 
 
 
 \section{L'I/O su terminale}
 \label{sec:sess_terminal_io}
 
 
 
 
 \section{L'I/O su terminale}
 \label{sec:sess_terminal_io}
 
-Esamineremo in questa sezione le peculiarità dell'I/O eseguito sui terminali,
-tenendo conto delle differenze che quest'ultimi presentano rispetto ai normali
-file su disco.
+Benché come ogni altro dispositivo i terminali siano accessibili come file,
+essi hanno assunto storicamente (essendo stati a lungo l'unico modo di
+accedere al sistema) una loro rilevanza specifica, che abbiamo già avuto modo
+di incontrare nella precedente sezione.
+
+Esamineremo qui le peculiarità dell'I/O eseguito sui terminali, che per la
+loro particolare natura presenta delle differenze rispetto ai normali file su
+disco e agli altri dispositivi.
+
+
+
+\subsection{L'architettura}
+\label{sec:term_design}
+
+
+I terminali sono una classe speciale di dispositivi a caratteri (si rammenti
+la classificazione di \secref{sec:file_file_types}); un terminale ha infatti
+una caratteristica che lo contraddistingue da un qualunque altro dispositivo,
+e cioè che è destinato a gestire l'interazione con un utente (deve essere in
+grado di fare da terminale di controllo per una sessione), che comportano la
+presenza di ulteriori capacità.
+
+L'interfaccia per i terminali è una delle più oscure e complesse, essendosi
+stratificata dagli inizi dei sistemi Unix fino ad oggi. Questo comporta una
+grande quantità di opzioni e controlli relativi ad un insieme di
+caratteristiche (come ad esempio la velocità della linea) necessarie per
+dispositivi, come i terminali seriali, che al giorno d'oggi sono praticamente
+in disuso.
+
+Storicamente i primi terminali erano appunto terminali di telescriventi
+(\textit{teletype}), da cui deriva sia il nome dell'interfaccia, \textit{TTY},
+che quello dei relativi file di dispositivo, che sono sempre della forma
+\texttt{/dev/tty*}.\footnote{ciò vale solo in parte per i terminali virtuali,
+  essi infatti hanno due lati, un \textit{master}, che può assumere i nomi
+  \file{/dev/pty[p-za-e][0-9a-f]} ed un corrispondente \textit{slave} con nome
+  \file{/dev/tty[p-za-e][0-9a-f]}.}  Oggi essi includono le porte seriali, le
+console virtuali dello schermo, i terminali virtuali che vengono creati come
+canali di comunicazione dal kernel e che di solito vengono associati alle
+connessioni di rete (ad esempio per trattare i dati inviati con \cmd{telnet} o
+\cmd{ssh}).
+
+% In generale tutti i terminali hanno un insieme di funzionalità comuni, che
+% vengono chiamate \textsl{discipline di linea}; esse contraddistinguono le
+% modalità con cui il kernel manipola (ad esempio la reazione ad un carattere di
+% cancellazione per la tastiera, o la gestione della linea tramite PPP o SLIP) i
+% dati grezzi che vengono immessi sul dispositivo; 
+
+
+L'I/O sui terminali si effettua con le stesse modalità dei file normali, si
+apre il relativo file di dispositivo, e si leggono e scriveno i dati con le
+usuali funzioni di lettura e scrittura, occorre però tenere conto delle loro
+caratteristiche specifiche, essi infatti prevedono due modalità di operazione,
+dette rispettivamente \textsl{modo canonico} e \textsl{modo non canonico}, che
+prevedono dei comportamenti nettamente diversi.
+
+La modalità preimpostata all'apertura del terminale è quella canonica, in cui
+le operazioni di lettura vengono sempre effettuate assemblando i dati in una
+linea;\footnote{per cui eseguendo una \func{read} su un terminale in modo
+  canonico la funzione si bloccherà, anche se si sono scritti dei caratteri,
+  fintanto che non si preme il tasto di ritorno a capo: a questo punto la
+  linea sarà completa e la funzione ritornerà.} ed in cui alcuni caratteri
+vengono interpretati per compiere operazioni (come la generazione dei segnali
+illustrati in \secref{sec:sig_job_control}), questa di norma è la modalità in
+cui funziona la shell.
+
+Un terminale in modo non canonico invece non effettua nessun accorpamento dei
+dati in linee né li interpreta; esso viene di solito usato dai programmi (gli
+editor ad esempio) che necessitano di poter leggere un carattere alla volta e
+che gestiscono al loro interno i vari comandi.
+
+La struttura dell'I/O, come di solito viene gestito dal driver del terminale è
+mostrata in \secref{fig:term_struct}
+
+\begin{figure}[htb]
+  \centering
+  \includegraphics[width=13cm]{img/term_struct}
+  \caption{Struttura interna generica di un driver per un terminale.}
+  \label{fig:term_struct}
+\end{figure}
+
+
+L'I/O viene controllato attraverso una serie di attributi mantenuti per
+ciascun terminale in una struttura \var{termios}, i cui campi
+
+
+\begin{figure}[!htb] 
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}[labelstep=0]{}
+struct termios {
+    tcflag_t c_iflag;      /* input modes */
+    tcflag_t c_oflag;      /* output modes */
+    tcflag_t c_cflag;      /* control modes */
+    tcflag_t c_lflag;      /* local modes */
+    cc_t c_cc[NCCS];       /* control chars */
+};
+    \end{lstlisting}
+  \end{minipage} 
+  \normalsize 
+  \caption{La struttura \var{termios}, che identifica le proprietà di un
+    terminale.} 
+  \label{fig:term_termios}
+\end{figure}
+
+
+
+\subsection{Il \textsl{modo canonico}}
+\label{sec:term_canonic_mode}
+
+Il modo canonico 
+
+
+\subsection{Il \textsl{modo non canonico}}
+\label{sec:term_noncanonic_mode}
+
+Il modo non canonico