1 \chapter{Terminali e sessioni di lavoro}
4 I terminali per lungo tempo tempo sono stati l'unico modo per accedere al
5 sistema, per questo anche oggi che esistono molte altre interfacce, essi
6 continuano a coprire un ruolo particolare, restando strettamente legati al
7 funzionamento dell'interfaccia a linea di comando.
9 Nella prima parte del capitolo esamineremo i concetti base del sistema delle
10 sessioni di lavoro, vale a dire il metodo con cui il kernel permette ad un
11 utente di gestire le capacità multitasking del sistema, permettendo di
12 eseguire più programmi in contemporanea. Nella seconda parte del capitolo
13 tratteremo poi il funzionamento dell'I/O su terminale, e delle varie
14 peculiarità che esso viene ad assumere a causa del suo stretto legame con il
15 suo uso come interfaccia di accesso al sistema da parte degli utenti.
18 \section{Il \textit{job control}}
19 \label{sec:sess_job_control}
21 Viene comunemente chiamato \textit{job control} quell'insieme di funzionalità
22 il cui scopo è quello di permettere ad un utente di poter sfruttare le
23 capacità multitasking di un sistema Unix per eseguire in contemporanea più
24 processi, pur potendo accedere, di solito, ad un solo terminale,\footnote{con
25 X e con i terminali virtuali tutto questo non è più vero, dato che si può
26 accedere a molti terminali in contemporanea da una singola postazione di
27 lavoro, ma il sistema è nato prima dell'esistenza di tutto ciò.} avendo cioè
28 un solo punto in cui si può avere accesso all'input ed all'output degli
32 \subsection{Una panoramica introduttiva}
33 \label{sec:sess_job_control_overview}
35 Il \textit{job control} è una caratteristica opzionale, introdotta in BSD
36 negli anni '80, e successivamente standardizzata da POSIX.1; la sua
37 disponibilità nel sistema è verificabile attraverso il controllo della macro
38 \macro{\_POSIX\_JOB\_CONTROL}. In generale il \textit{job control} richiede il
39 supporto sia da parte della shell (quasi tutte ormai lo fanno), che da parte
40 del kernel; in particolare il kernel deve assicurare sia la presenza di un
41 driver per i terminali abilitato al \textit{job control} che quella dei
42 relativi segnali illustrati in \secref{sec:sig_job_control}.
44 In un sistema che supporta il \textit{job control}, una volta completato il
45 login, l'utente avrà a disposizione una shell dalla quale eseguire i comandi e
46 potrà iniziare quella che viene chiamata una \textsl{sessione}, che riunisce
47 (vedi \secref{sec:sess_proc_group}) tutti i processi eseguiti all'interno
48 dello stesso login (esamineremo tutto il processo in dettaglio in
49 \secref{sec:sess_login}).
51 Siccome la shell è collegata ad un solo terminale, che viene usualmente
52 chiamato \textsl{terminale di controllo}, (vedi \secref{sec:sess_ctrl_term})
53 un solo comando alla volta (quello che viene detto in \textit{foreground}),
54 potrà scrivere e leggere dal terminale. La shell però può eseguire anche più
55 comandi in contemporanea, mandandoli in \textit{background} (aggiungendo una
56 \cmd{\&} alla fine del comando), nel qual caso essi saranno eseguiti senza
57 essere collegati al terminale.
59 Si noti come si sia parlato di comandi e non di programmi o processi; fra le
60 funzionalità della shell infatti c'è anche quella di consentire di concatenare
61 più programmi in una sola riga di comando con le pipe, ed in tal caso verranno
62 eseguiti più programmi, inoltre, anche quando si invoca un singolo programma,
63 questo potrà sempre lanciare sottoprocessi per eseguire dei compiti specifici.
65 Per questo l'esecuzione di un comando può originare più di un processo; quindi
66 nella gestione del job control non si può far riferimento ai singoli processi.
67 Per questo il kernel prevede la possibilità di raggruppare più processi in un
68 \textit{process group} (detto anche \textsl{raggruppamento di processi}, vedi
69 \secref{sec:sess_proc_group}) e la shell farà sì che tutti i processi che
70 originano da una riga di comando appartengano allo stesso raggruppamento, in
71 modo che le varie funzioni di controllo, ed i segnali inviati dal terminale,
72 possano fare riferimento ad esso.
74 In generale allora all'interno di una sessione avremo un eventuale (può non
75 esserci) \textit{process group} in \textit{foreground}, che riunisce i
76 processi che possono accedere al terminale, e più \textit{process group} in
77 \textit{background}, che non possono accedervi. Il job control prevede che
78 quando un processo appartenente ad un raggruppamento in \textit{background}
79 cerca di accedere al terminale, venga inviato un segnale a tutti i processi
80 del raggruppamento, in modo da bloccarli (vedi \secref{sec:sess_ctrl_term}).
82 Un comportamento analogo si ha anche per i segnali generati dai comandi di
83 tastiera inviati dal terminale che vengono inviati a tutti i processi del
84 raggruppamento in \textit{foreground}. In particolare \cmd{C-z} interrompe
85 l'esecuzione del comando, che può poi essere mandato in \textit{background}
86 con il comando \cmd{bg}.\footnote{si tenga presente che \cmd{bg} e \cmd{fg}
87 sono parole chiave che indicano comandi interni alla shell, e nel caso non
88 comportano l'esecuzione di un programma esterno.} Il comando \cmd{fg}
89 consente invece di mettere in \textit{foreground} un comando precedentemente
90 lanciato in \textit{background}.
92 Di norma la shell si cura anche di notificare all'utente (di solito prima
93 della stampa a video del prompt) lo stato dei vari processi; essa infatti sarà
94 in grado, grazie all'uso di \func{waitpid}, di rilevare sia i processi che
95 sono terminati, sia i raggruppamenti che sono bloccati (in questo caso usando
96 l'opzione \macro{WUNTRACED}, secondo quanto illustrato in
97 \secref{sec:proc_wait}).
100 \subsection{I \textit{process group} e le \textsl{sessioni}}
101 \label{sec:sess_proc_group}
103 Come accennato in \secref{sec:sess_job_control_overview} nel job control i
104 processi vengono raggruppati in \textit{process group} e \textit{sessioni};
105 per far questo vengono utilizzati due ulteriori identificatori (oltre quelli
106 visti in \secref{sec:proc_pid}) che il kernel associa a ciascun
107 processo:\footnote{in Linux questi identificatori sono mantenuti nei campi
108 \var{pgrp} e \var{session} della struttura \var{task\_struct} definita in
109 \file{sched.h}.} l'identificatore del \textit{process group} e
110 l'identificatore della \textsl{sessione}, che vengono indicati rispettivamente
111 con le sigle \acr{pgid} e \acr{sid}, e sono mantenuti in variabili di tipo
112 \type{pid\_t}. I valori di questi identificatori possono essere visualizzati
113 dal comando \cmd{ps} usando l'opzione \cmd{-j}.
115 Un \textit{process group} è pertanto definito da tutti i processi che hanno lo
116 stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con
117 le funzioni \func{getpgid} e \func{getpgrp},\footnote{\func{getpgrp} è
118 definita nello standard POSIX.1, mentre \func{getpgid} è richiesta da SVr4.}
119 i cui prototipi sono:
123 \funcdecl{pid\_t getpgid(pid\_t pid)}
124 Legge il \acr{pgid} del processo \param{pid}.
126 \funcdecl{pid\_t getpgrp(void)}
127 Legge il \acr{pgid} del processo corrente.
129 \bodydesc{Le funzioni restituiscono il \acr{pgid} del processo,
130 \func{getpgrp} ha sempre successo, mentre \func{getpgid} restituisce -1
131 ponendo \var{errno} a \macro{ESRCH} se il processo selezionato non esiste.}
134 La funzione \func{getpgid} permette di specificare il \acr{pid} del processo
135 di cui si vuole sapere il \acr{pgid}; un valore nullo per \param{pid}
136 restituisce il \acr{pgid} del processo corrente; \func{getpgrp} è di norma
137 equivalente a \code{getpgid(0)}.
139 In maniera analoga l'identificatore della sessione può essere letto dalla
140 funzione \func{getsid}, che però nelle \acr{glibc}\footnote{la system call è
141 stata introdotta in Linux a partire dalla versione 1.3.44, il supporto nelle
142 librerie del C è iniziato dalla versione 5.2.19. La funzione non è prevista
143 da POSIX.1, che parla solo di processi leader di sessione, e non di
144 identificatori di sessione.} è accessibile solo definendo
145 \macro{\_XOPEN\_SOURCE} e \macro{\_XOPEN\_SOURCE\_EXTENDED}; il suo prototipo
147 \begin{prototype}{unistd.h}{pid\_t getsid(pid\_t pid)}
148 Legge l'identificatore di sessione del processo \param{pid}.
150 \bodydesc{La funzione restituisce l'identificatore (un numero positivo) in
151 caso di successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà
154 \item[\macro{ESRCH}] Il processo selezionato non esiste.
155 \item[\macro{EPERM}] In alcune implementazioni viene restituito quando il
156 processo selezionato non fa parte della stessa sessione del processo
162 Entrambi gli identificatori vengono inizializzati alla creazione di ciascun
163 processo con lo stesso valore che hanno nel processo padre, per cui un
164 processo appena creato appartiene sempre allo stesso raggruppamento e alla
165 stessa sessione del padre. Vedremo poi come sia possibile creare più
166 \textit{process group} all'interno della stessa sessione, e spostare i
167 processi dall'uno all'altro, ma sempre all'interno di una stessa sessione.
169 Ciascun raggruppamento di processi ha sempre un processo principale, il
170 cosiddetto \textit{process group leader}, che è identificato dall'avere un
171 \acr{pgid} uguale al suo \acr{pid}, in genere questo è il primo processo del
172 raggruppamento, che si incarica di lanciare tutti gli altri. Un nuovo
173 raggruppamento si crea con la funzione \func{setpgrp},\footnote{questa è la
174 definizione di POSIX.1, BSD definisce una funzione con lo stesso nome, che
175 però è identica a \func{setpgid}; nelle \acr{glibc} viene sempre usata
176 sempre questa definizione, a meno di non richiedere esplicitamente la
177 compatibilità all'indietro con BSD, definendo la macro
178 \macro{\_BSD\_SOURCE}.} il cui prototipo è:
179 \begin{prototype}{unistd.h}{int setpgrp(void)}
180 Modifica il \acr{pgid} al valore del \acr{pid} del processo corrente.
182 \bodydesc{La funzione restituisce il valore del nuovo \textit{process
186 La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo
187 corrente, rende questo \textit{group leader} di un nuovo raggruppamento, tutti
188 i successivi processi da esso creati apparterranno (a meno di non cambiare di
189 nuovo il \acr{pgid}) al nuovo raggruppamento. È possibile invece spostare un
190 processo da un raggruppamento ad un altro con la funzione \func{setpgid}, il
192 \begin{prototype}{unistd.h}{int setpgid(pid\_t pid, pid\_t pgid)}
193 Assegna al \acr{pgid} del processo \param{pid} il valore \param{pgid}.
195 \bodydesc{La funzione ritorna il valore del nuovo \textit{process group}, e
196 -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
198 \item[\macro{ESRCH}] Il processo selezionato non esiste.
199 \item[\macro{EPERM}] Il cambiamento non è consentito.
200 \item[\macro{EACCESS}] Il processo ha già eseguito una \func{exec}.
201 \item[\macro{EINVAL}] Il valore di \param{pgid} è negativo.
206 La funzione permette di cambiare il \acr{pgid} del processo \param{pid}, ma il
207 cambiamento può essere effettuato solo se \param{pgid} indica un
208 \textit{process group} che è nella stessa sessione del processo chiamante.
209 Inoltre la funzione può essere usata soltanto sul processo corrente o su uno
210 dei suoi figli, ed in quest'ultimo caso ha successo soltanto se questo non ha
211 ancora eseguito una \func{exec}.\footnote{questa caratteristica è implementata
212 dal kernel che mantiene allo scopo un altro campo, \var{did\_exec}, in
213 \var{task\_struct}.} Specificando un valore nullo per \param{pid} si indica
214 il processo corrente, mentre specificando un valore nullo per \param{pgid} si
215 imposta il \textit{process group} al valore del \acr{pid} del processo
216 selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0, 0)}.
218 Di norma questa funzione viene usata dalla shell quando si usano delle
219 pipeline, per mettere nello stesso process group tutti i programmi lanciati su
220 ogni linea di comando; essa viene chiamata dopo una \func{fork} sia dal
221 processo padre, per impostare il valore nel figlio, che da quest'ultimo, per
222 sé stesso, in modo che il cambiamento di \textit{process group} sia immediato
223 per entrambi; una delle due chiamate sarà ridondante, ma non potendo
224 determinare quale dei due processi viene eseguito per primo, occorre eseguirle
225 comunque entrambe per evitare di esporsi ad una race condition.
227 Si noti come nessuna delle funzioni esaminate finora permetta di spostare un
228 processo da una sessione ad un altra; infatti l'unico modo di far cambiare
229 sessione ad un processo è quello di crearne una nuova con l'uso di
230 \func{setsid}; il suo prototipo è:
231 \begin{prototype}{unistd.h}{pid\_t setsid(void)}
232 Crea una nuova sessione sul processo corrente impostandone \acr{sid} e
235 \bodydesc{La funzione ritorna il valore del nuovo \acr{sid}, e -1 in caso di
236 errore, il solo errore possibile è \macro{EPERM}, che si ha quando il
237 \acr{pgid} e \acr{pid} del processo coincidono.}
240 La funzione imposta il \acr{pgid} ed il \acr{sid} del processo corrente al
241 valore del suo \acr{pid}, creando così una nuova sessione ed un nuovo
242 \textit{process group} di cui esso diventa leader (come per i \textit{process
243 group} un processo si dice leader di sessione\footnote{in Linux la proprietà
244 è mantenuta in maniera indipendente con un apposito campo \var{leader} in
245 \var{task\_struct}.} se il suo \acr{sid} è uguale al suo \acr{pid}) ed unico
246 componente. Inoltre la funzione distacca il processo da ogni terminale di
247 controllo (torneremo sull'argomento in \secref{sec:sess_ctrl_term}) cui fosse
248 in precedenza associato.
250 funzione ha successo soltanto se il processo non è già leader di un
251 \textit{process group}, per cui per usarla di norma si esegue una \func{fork}
252 e si esce, per poi chiamare \func{setsid} nel processo figlio, in modo che,
253 avendo questo lo stesso \acr{pgid} del padre ma un \acr{pid} diverso, non ci
254 siano possibilità di errore.\footnote{potrebbe sorgere il dubbio che, per il
255 riutilizzo dei valori dei \acr{pid} fatto nella creazione dei nuovi processi
256 (vedi \secref{sec:proc_pid}), il figlio venga ad assumere un valore
257 corrispondente ad un process group esistente; questo viene evitato dal
258 kernel che considera come disponibili per un nuovo \acr{pid} solo valori che
259 non corrispondono ad altri \acr{pid}, \acr{pgid} o \acr{sid} in uso nel
260 sistema.} Questa funzione viene usata di solito nel processo di login (per i
261 dettagli vedi \secref{sec:sess_login}) per raggruppare in una sessione tutti i
262 comandi eseguiti da un utente dalla sua shell.
266 \subsection{Il terminale di controllo e il controllo di sessione}
267 \label{sec:sess_ctrl_term}
269 Come accennato in \secref{sec:sess_job_control_overview}, nel sistema del
270 \textit{job control} i processi all'interno di una sessione fanno riferimento
271 ad un terminale di controllo (ad esempio quello su cui si è effettuato il
272 login), sul quale effettuano le operazioni di lettura e
273 scrittura,\footnote{nel caso di login grafico la cosa può essere più
274 complessa, e di norma l'I/O è effettuato tramite il server X, ma ad esempio
275 per i programmi, anche grafici, lanciati da un qualunque emulatore di
276 terminale, sarà quest'ultimo a fare da terminale (virtuale) di controllo.} e
277 dal quale ricevono gli eventuali segnali da tastiera.
279 A tale scopo lo standard POSIX.1 prevede che ad ogni sessione possa essere
280 associato un terminale di controllo; in Linux questo viene realizzato
281 mantenendo fra gli attributi di ciascun processo anche qual'è il suo terminale
282 di controllo. \footnote{Lo standard POSIX.1 non specifica nulla riguardo
283 l'implementazione; in Linux anch'esso viene mantenuto nella solita struttura
284 \var{task\_struct}, nel campo \var{tty}.} In generale ogni processo eredita
285 dal padre, insieme al \acr{pgid} e al \acr{sid} anche il terminale di
286 controllo (vedi \secref{sec:proc_fork}). In questo modo tutti processi
287 originati dallo stesso leader di sessione mantengono lo stesso terminale di
290 Alla creazione di una nuova sessione con \func{setsid} ogni associazione con
291 il precedente terminale di controllo viene cancellata, ed il processo che è
292 divenuto un nuovo leader di sessione dovrà riottenere\footnote{solo quando ciò
293 è necessario, cosa che, come vedremo in \secref{sec:sess_daemon}, non è
294 sempre vera.}, un terminale di controllo. In generale questo viene fatto
295 automaticamente dal sistema\footnote{a meno di non avere richiesto
296 esplicitamente che questo non diventi un terminale di controllo con il flag
297 \macro{O\_NOCTTY} (vedi \secref{sec:file_open}). In questo Linux segue la
298 semantica di SVr4; BSD invece richiede che il terminale venga allocato
299 esplicitamente con una \func{ioctl} con il comando \macro{TIOCSCTTY}.}
300 quando viene aperto il primo terminale (cioè uno dei vari file di dispositivo
301 \file{/dev/tty*}) che diventa automaticamente il terminale di controllo,
302 mentre il processo diventa il \textsl{processo di controllo} di quella
305 In genere (a meno di redirezioni) nelle sessioni di lavoro questo terminale è
306 associato ai file standard (di input, output ed error) dei processi nella
307 sessione, ma solo quelli che fanno parte del cosiddetto raggruppamento di
308 \textit{foreground}, possono leggere e scrivere in certo istante. Per
309 impostare il raggruppamento di \textit{foreground} di un terminale si usa la
310 funzione \func{tcsetpgrp}, il cui prototipo è:
315 \funcdecl{int tcsetpgrp(int fd, pid\_t pgrpid)} Imposta a \param{pgrpid} il
316 \textit{process group} di \textit{foreground} del terminale associato al
317 file descriptor \param{fd}.
319 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
320 errore, nel qual caso \var{errno} assumerà i valori:
322 \item[\macro{ENOTTY}] Il file \param{fd} non corrisponde al terminale di
323 controllo del processo chiamante.
324 \item[\macro{ENOSYS}] Il sistema non supporta il job control.
325 \item[\macro{EPERM}] Il \textit{process group} specificato non è nella
326 stessa sessione del processo chiamante.
328 ed inoltre \macro{EBADF} ed \macro{EINVAL}.
331 \noindent la funzione può essere eseguita con successo solo da
332 un processo nella stessa sessione e con lo stesso terminale di controllo.
334 Come accennato in \secref{sec:sess_job_control_overview}, tutti i processi (e
335 relativi raggruppamenti) che non fanno parte del gruppo di \textit{foreground}
336 sono detti in \textit{background}; se uno si essi cerca di accedere al
337 terminale di controllo provocherà l'invio da parte del kernel di uno dei due
338 segnali \macro{SIGTTIN} o \macro{SIGTTOU} (a seconda che l'accesso sia stato
339 in lettura o scrittura) a tutto il suo \textit{process group}; dato che il
340 comportamento di default di questi segnali (si riveda quanto esposto in
341 \secref{sec:sig_job_control}) è di fermare il processo, di norma questo
342 comporta che tutti i membri del gruppo verranno fermati, ma non si avranno
343 condizioni di errore.\footnote{la shell in genere notifica comunque un
344 avvertimento, avvertendo la presenza di processi bloccati grazie all'uso di
345 \func{waitpid}.} Se però si bloccano o ignorano i due segnali citati, le
346 funzioni di lettura e scrittura falliranno con un errore di \macro{EIO}.
348 Un processo può controllare qual'è il gruppo di \textit{foreground} associato
349 ad un terminale con la funzione \func{tcgetpgrp}, il cui prototipo è:
351 \headdecl{unistd.h} \headdecl{termios.h}
353 \funcdecl{pid\_t tcgetpgrp(int fd)} Legge il \textit{process group} di
354 \textit{foreground} del terminale associato al file descriptor \param{fd}.
355 \bodydesc{La funzione restituisce in caso di successo il \acr{pgid} del
356 gruppo di \textit{foreground}, e -1 in caso di errore, nel qual caso
357 \var{errno} assumerà i valori:
359 \item[\macro{ENOTTY}] Non c'è un terminale di controllo o \param{fd} non
360 corrisponde al terminale di controllo del processo chiamante.
362 ed inoltre \macro{EBADF} ed \macro{ENOSYS}.
366 Si noti come entrambe le funzioni usino come argomento il valore di un file
367 descriptor, il risultato comunque non dipende dal file descriptor che si usa
368 ma solo dal terminale cui fa riferimento; il kernel inoltre permette a ciascun
369 processo di accedere direttamente al suo terminale di controllo attraverso il
370 file speciale \file{/dev/tty}, che per ogni processo è un sinonimo per il
371 proprio terminale di controllo. Questo consente anche a processi che possono
372 aver rediretto l'output di accedere al terminale di controllo, pur non
373 disponendo più del file descriptor originario; un caso tipico è il programma
374 \cmd{crypt} che accetta la redirezione sullo standard input di un file da
375 decifrare, ma deve poi leggere la password dal terminale.
377 Un'altra caratteristica del terminale di controllo usata nel job control è che
378 utilizzando su di esso le combinazioni di tasti speciali (\cmd{C-z},
379 \cmd{C-c}, \cmd{C-y} e \verb|C-\|) si farà sì che il kernel invii i
380 corrispondenti segnali (rispettivamente \macro{SIGTSTP}, \macro{SIGINT},
381 \macro{SIGQUIT} e \macro{SIGTERM}, trattati in \secref{sec:sig_job_control}) a
382 tutti i processi del raggruppamento di \textit{foreground}; in questo modo la
383 shell può gestire il blocco e l'interruzione dei vari comandi.
385 Per completare la trattazione delle caratteristiche del job control legate al
386 terminale di controllo, occorre prendere in considerazione i vari casi legati
387 alla terminazione anomala dei processi, che sono di norma gestite attraverso
388 il segnale \macro{SIGHUP}. Il nome del segnale deriva da \textit{hungup},
389 termine che viene usato per indicare la condizione in cui il terminale diventa
390 inutilizzabile, (letteralmente sarebbe \textsl{impiccagione}).
392 Quando si verifica questa condizione, ad esempio se si interrompe la linea, o
393 va giù la rete o più semplicemente si chiude forzatamente la finestra di
394 terminale su cui si stava lavorando, il kernel provvederà ad inviare il
395 segnale di \macro{SIGHUP} al processo di controllo. L'azione preimpostata in
396 questo caso è la terminazione del processo, il problema che si pone è cosa
397 accade agli altri processi nella sessione, che non han più un processo di
398 controllo che possa gestire l'accesso al terminale, che potrebbe essere
399 riutilizzato per qualche altra sessione.
401 Lo standard POSIX.1 prevede che quando il processo di controllo termina, che
402 ciò avvenga o meno per un \textit{hungup} del terminale (ad esempio si
403 potrebbe terminare direttamente la shell con \cmd{kill}) venga inviato un
404 segnale di \macro{SIGHUP} ai processi del raggruppamento di foreground. In
405 questo modo essi potranno essere avvisati che non esiste più un processo in
406 grado di gestire il terminale (di norma tutto ciò comporta la terminazione
407 anche di questi ultimi).
409 Restano però gli eventuali processi in background, che non ricevono il
410 segnale; in effetti se il terminale non dovesse più servire essi potrebbero
411 proseguire fino al completamento della loro esecuzione; ma si pone il problema
412 di come gestire quelli che sono bloccati, o che si bloccano nell'accesso al
413 terminale, in assenza di un processo che sia in grado di effettuare il
414 controllo dello stesso.
416 Questa è la situazione in cui si ha quello che viene chiamato un
417 \textit{orphaned process group}. Lo standard POSIX.1 lo definisce come un
418 \textit{process group} i cui processi hanno come padri esclusivamente o altri
419 processi nel raggruppamento, o processi fuori della sessione. Lo standard
420 prevede inoltre che se la terminazione di un processo fa sì che un
421 raggruppamento di processi diventi orfano e se i suoi membri sono bloccati, ad
422 essi vengano inviati in sequenza i segnali di \macro{SIGHUP} e
425 La definizione può sembrare complicata, e a prima vista non è chiaro cosa
426 tutto ciò abbia a che fare con il problema della terminazione del processo di
427 controllo. Consideriamo allora cosa avviene di norma nel \textit{job
428 control}: una sessione viene creata con \func{setsid} che crea anche un
429 nuovo process group: per definizione quest'ultimo è sempre \textsl{orfano},
430 dato che il padre del leader di sessione è fuori dalla stessa e il nuovo
431 process group contiene solo il leader di sessione. Questo è un caso limite, e
432 non viene emesso nessun segnale perché quanto previsto dallo standard riguarda
433 solo i raggruppamenti che diventano orfani in seguito alla terminazione di un
434 processo.\footnote{l'emissione dei segnali infatti avviene solo nella fase di
435 uscita del processo, come una delle operazioni legate all'esecuzione di
436 \func{\_exit}, secondo quanto illustrato in \secref{sec:proc_termination}.}
438 Il leader di sessione provvederà a creare nuovi raggruppamenti che a questo
439 punto non sono orfani in quanto esso resta padre per almeno uno dei processi
440 del gruppo (gli altri possono derivare dal primo). Alla terminazione del
441 leader di sessione però avremo che, come visto in
442 \secref{sec:proc_termination}, tutti i suoi figli vengono adottati da
443 \cmd{init}, che è fuori dalla sessione. Questo renderà orfani tutti i process
444 group creati direttamente dal leader di sessione (a meno di non aver spostato
445 con \func{setpgid} un processo da un gruppo ad un altro, cosa che di norma non
446 viene fatta) i quali riceveranno, nel caso siano bloccati, i due segnali;
447 \macro{SIGCONT} ne farà proseguire l'esecuzione, ed essendo stato nel
448 frattempo inviato anche \macro{SIGHUP}, se non c'è un gestore per
449 quest'ultimo, i processi bloccati verranno automaticamente terminati.
453 \subsection{Dal login alla shell}
454 \label{sec:sess_login}
456 L'organizzazione del sistema del job control è strettamente connessa alle
457 modalità con cui un utente accede al sistema per dare comandi, collegandosi ad
458 esso con un terminale, che sia questo realmente tale, come un VT100 collegato
459 ad una seriale o virtuale, come quelli associati a schermo e tastiera o ad una
460 connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla
461 fine le differenze sono\footnote{in generale nel caso di login via rete o di
462 terminali lanciati dall'interfaccia grafica cambia anche il processo da cui
463 ha origine l'esecuzione della shell.} nel dispositivo cui il kernel associa i
464 file standard (vedi \secref{sec:file_std_descr}) per l'I/O, tratteremo solo il
465 caso classico del terminale.
467 Abbiamo già brevemente illustrato in \secref{sec:intro_kern_and_sys} le
468 modalità con cui il sistema si avvia, e di come, a partire da \cmd{init},
469 vengano lanciati tutti gli altri processi. Adesso vedremo in maniera più
470 dettagliata le modalità con cui il sistema arriva a fornire ad un utente la
471 shell che gli permette di lanciare i suoi comandi su un terminale.
473 Nella maggior parte delle distribuzioni di GNU/Linux\footnote{fa eccezione la
474 distribuzione \textit{Slackware}, come alcune distribuzioni su dischetto, ed
475 altre distribuzioni dedicate a compiti limitati e specifici.} viene usata
476 la procedura di avvio di System V; questa prevede che \cmd{init} legga dal
477 file di configurazione \file{/etc/inittab} quali programmi devono essere
478 lanciati, ed in quali modalità, a seconda del cosiddetto \textit{run level},
479 anch'esso definito nello stesso file.
481 Tralasciando la descrizione del sistema dei run level, (per il quale si
482 rimanda alla lettura delle pagine di manuale di \cmd{init} e di
483 \file{inittab}) quello che comunque viene sempre fatto è di eseguire almeno
484 una istanza di un programma che permetta l'accesso ad un terminale. Uno schema
485 di massima della procedura è riportato in \figref{fig:sess_term_login}.
489 \includegraphics[width=15cm]{img/tty_login}
490 \caption{Schema della procedura di login su un terminale.}
491 \label{fig:sess_term_login}
494 Un terminale, che esso sia un terminale effettivo, attaccato ad una seriale o
495 ad un altro tipo di porta di comunicazione, o una delle console virtuali
496 associate allo schermo, viene sempre visto attraverso attraverso un device
497 driver che ne presenta un'interfaccia comune su un apposito file di
500 Per controllare un terminale si usa di solito il programma \cmd{getty} (od una
501 delle sue varianti), che permette di mettersi in ascolto su uno di questi
502 dispositivi. Alla radice della catena che porta ad una shell per i comandi
503 perciò c'è sempre \cmd{init} che esegue prima una \func{fork} e poi una
504 \func{exec} per lanciare una istanza di questo programma su un terminale, il
505 tutto ripetuto per ciascuno dei terminali che si hanno a disposizione (o per
506 un certo numero di essi, nel caso delle console virtuali), secondo quanto
507 indicato dall'amministratore nel file di configurazione del programma,
510 Quando viene lanciato da \cmd{init} il programma parte con i privilegi di
511 amministratore e con un ambiente vuoto; \cmd{getty} si cura di chiamare
512 \func{setsid} per creare una nuova sessione ed un nuovo process group, e di
513 aprire il terminale (che così diventa il terminale di controllo della
514 sessione) in lettura sullo standard input ed in scrittura sullo standard
515 output e sullo standard error; inoltre effettuerà, qualora servano, ulteriori
516 settaggi.\footnote{ad esempio, come qualcuno si sarà accorto scrivendo un nome
517 di login in maiuscolo, può effettuare la conversione automatica dell'input
518 in minuscolo, ponendosi in una modalità speciale che non distingue fra i due
519 tipi di caratteri (a beneficio di alcuni vecchi terminali che non
520 supportavano le minuscole).} Alla fine il programma stamperà un messaggio di
521 benvenuto per poi porsi in attesa dell'immissione del nome di un utente.
523 Una volta che si sia immesso il nome di login \cmd{getty} esegue direttamente
524 il programma \cmd{login} con una \func{exevle}, passando come argomento la
525 stringa con il nome, ed un ambiente opportunamente costruito che contenga
526 quanto necessario (ad esempio di solito viene opportunamente inizializzata la
527 variabile di ambiente \texttt{TERM}) ad identificare il terminale su cui si
528 sta operando, a beneficio dei programmi che verranno lanciati in seguito.
530 A sua volta \cmd{login}, che mantiene i privilegi di amministratore, usa il
531 nome dell'utente per effettuare una ricerca nel database degli
532 utenti,\footnote{in genere viene chiamata \func{getpwnam}, che abbiamo visto
533 in \secref{sec:sys_user_group}, per leggere la password e gli altri dati dal
534 database degli utenti.} e richiede una password. Se l'utente non esiste o se
535 la password non corrisponde\footnote{il confronto non viene effettuato con un
536 valore in chiaro; quanto immesso da terminale viene invece a sua volta
537 criptato, ed è il risultato che viene confrontato con il valore che viene
538 mantenuto nel database degli utenti.} la richiesta viene ripetuta un certo
539 numero di volte dopo di che \cmd{login} esce ed \cmd{init} provvede a
540 rilanciare un'altra istanza di \func{getty}.
542 Se invece la password corrisponde \cmd{login} esegue \func{chdir} per settare
543 la \textit{home directory} dell'utente, cambia i diritti di accesso al
544 terminale (con \func{chown} e \func{chmod}) per assegnarne la titolarità
545 all'utente ed al suo gruppo principale, assegnandogli al contempo i diritti di
546 lettura e scrittura. Inoltre il programma provvede a costruire gli opportuni
547 valori per le variabili di ambiente, come \texttt{HOME}, \texttt{SHELL}, ecc.
548 Infine attraverso l'uso di \func{setuid}, \func{setpid} e \func{initgroups}
549 verrà cambiata l'identità del proprietario del processo, infatti, come
550 spiegato in \secref{sec:proc_setuid}, avendo invocato tali funzioni con i
551 privilegi di amministratore, tutti gli userid ed i groupid (reali, effettivi e
552 salvati) saranno settati a quelli dell'utente.
554 A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
555 iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
556 ad eseguire con un'altra \func{exec} la shell, che si troverà con un ambiente
557 già pronto con i file standard di \secref{sec:file_std_descr} impostati sul
558 terminale, e pronta, nel ruolo di leader di sessione e di processo di
559 controllo per il terminale, a gestire l'esecuzione dei comandi come illustrato
560 in \secref{sec:sess_job_control_overview}.
562 Dato che il processo padre resta sempre \cmd{init} quest'ultimo potrà
563 provvedere, ricevendo un \macro{SIGCHLD} all'uscita della shell quando la
564 sessione di lavoro è terminata, a rilanciare \cmd{getty} sul terminale per
565 ripetere da capo tutto il procedimento.
569 \subsection{Prescrizioni per un programma \textit{daemon}}
570 \label{sec:sess_daemon}
572 Come sottolineato fin da \secref{sec:intro_base_concept}, in un sistema
573 unix-like tutte le operazioni sono eseguite tramite processi, comprese quelle
574 operazioni di sistema (come l'esecuzione dei comandi periodici, o la consegna
575 della posta, ed in generale tutti i programmi di servizio) che non hanno
576 niente a che fare con la gestione diretta dei comandi dell'utente.
578 Questi programmi, che devono essere eseguiti in modalità non interattiva e
579 senza nessun intervento dell'utente, sono normalmente chiamati
580 \textsl{demoni}, (o \textit{daemons}), nome ispirato dagli omonimi spiritelli
581 che svolgevano compiti vari, di cui parlava Socrate (che sosteneva di averne
582 uno al suo servizio).\footnote{NdT. ricontrollare, i miei ricordi di filosofia
583 sono piuttosto datati.}
585 Se però si lancia un programma demone dalla riga di comando in un sistema che
586 supporta, come Linux, il \textit{job control} esso verrà comunque associato ad
587 un terminale di controllo e mantenuto all'interno di una sessione, e anche se
588 può essere mandato in background e non eseguire più nessun I/O su terminale,
589 si avranno comunque tutte le conseguenze che abbiamo appena visto in
590 \secref{sec:sess_ctrl_term} (in particolare l'invio dei segnali in
591 corrispondenza dell'uscita del leader di sessione).
593 Per questo motivo un programma che deve funzionare come demone deve sempre
594 prendere autonomamente i provvedimenti opportuni (come distaccarsi dal
595 terminale e dalla sessione) ad impedire eventuali interferenze da parte del
596 sistema del \textit{job control}; questi sono riassunti in una lista di
597 prescrizioni\footnote{ad esempio sia Stevens in \cite{APUE}, che la
598 \textit{Unix Programming FAQ} \cite{UnixFAQ} ne riportano di sostanzialmente
599 identiche.} da seguire quando si scrive un demone.
601 Pertanto, quando si lancia un programma che deve essere eseguito come demone
602 occorrerà predisporlo in modo che esso compia le seguenti azioni:
604 \item Eseguire una \func{fork} e terminare immediatamente il processo padre
605 proseguendo l'esecuzione nel figlio. In questo modo si ha la certezza che
606 il figlio non è un \textit{process group leader}, (avrà il \acr{pgid} del
607 padre, ma un \acr{pid} diverso) e si può chiamare \func{setsid} con
608 successo. Inoltre la shell considererà terminato il comando all'uscita del
610 \item Eseguire \func{setsid} per creare una nuova sessione ed un nuovo
611 raggruppamento di cui il processo diventa automaticamente il leader, che
612 però non ha associato nessun terminale di controllo.
613 \item Assicurarsi che al processo non venga associato in seguito nessun nuovo
614 terminale di controllo; questo può essere fatto sia avendo cura di usare
615 sempre l'opzione \macro{O\_NOCTTY} nell'aprire i file di terminale, che
616 eseguendo una ulteriore \func{fork} uscendo nel padre e proseguendo nel
617 figlio. In questo caso, non essendo più quest'ultimo un leader di sessione
618 non potrà ottenere automaticamente un terminale di controllo.
619 \item Eseguire una \func{chdir} per impostare la directory di lavoro del
620 processo (su \file{/} o su una directory che contenga dei file necessari per
621 il programma), per evitare che la directory da cui si è lanciato il processo
622 resti in uso e non sia possibile rimuoverla o smontare il filesystem che la
624 \item Impostare la maschera dei permessi (di solito con \code{umask(0)}) in
625 modo da non essere dipendenti dal valore ereditato da chi ha lanciato
626 originariamente il processo.
627 \item Chiudere tutti i file aperti che non servono più (in generale tutti); in
628 particolare vanno chiusi i file standard che di norma sono ancora associati
629 al terminale (un'altra opzione è quella di redirigerli verso
634 In Linux buona parte di queste azioni possono venire eseguite invocando la
635 funzione \func{daemon}, introdotta per la prima volta in BSD4.4; il suo
637 \begin{prototype}{unistd.h}{int daemon(int nochdir, int noclose)}
638 Esegue le operazioni che distaccano il processo dal terminale di controllo e
639 lo fanno girare come demone.
641 \bodydesc{La funzione restituisce (nel nuovo processo) 0 in caso di
642 successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i
643 valori impostati dalle sottostanti \func{fork} e \func{setsid}.}
646 La funzione esegue una \func{fork}, per uscire subito, con \func{\_exit}, nel
647 padre, mentre l'esecuzione prosegue nel figlio che esegue subito una
648 \func{setsid}. In questo modo si compiono automaticamente i passi 1 e 2 della
649 precedente lista. Se \param{nochdir} è nullo la funzione imposta anche la
650 directory di lavoro su \file{/}, se \param{noclose} è nullo i file standard
651 vengono rediretti su \file{/dev/null} (corrispondenti ai passi 4 e 6); in caso
652 di valori non nulli non viene eseguita nessuna altra azione.
654 Dato che un programma demone non può più accedere al terminale, si pone il
655 problema di come fare per la notifica di eventuali errori, non potendosi più
656 utilizzare lo standard error; per il normale I/O infatti ciascun demone avrà
657 le sue modalità di interazione col sistema e gli utenti a seconda dei compiti
658 e delle funzionalità che sono sono previste; ma gli errori devono normalmente
659 essere notificati all'amministratore del sistema.
661 Una soluzione può essere quella di scrivere gli eventuali messaggi su uno
662 specifico file (cosa che a volte viene fatta comunque) ma questo comporta il
663 grande svantaggio che l'amministratore dovrà tenere sotto controllo un file
664 diverso per ciascun demone, e che possono anche generarsi conflitti di nomi.
665 Per questo in BSD4.2 venne introdotto un servizio di sistema, il
666 \textit{syslog}, che oggi si trova su tutti i sistemi Unix, e che permettesse
667 ai demoni di inviare messaggi all'amministratore in una maniera
670 Il servizio prevede vari meccanismi di notifica, e, come ogni altro servizio
671 in un sistema unix-like, viene gestito attraverso un apposito programma,
672 \cmd{syslogd}, che è anch'esso un \textsl{demone}. In generale i messaggi di
673 errore vengono raccolti dal file speciale \file{/dev/log}, un \textit{socket}
674 locale (vedi \secref{sec:sock_sa_local}) dedicato a questo scopo, o via rete,
675 con un \textit{socket} UDP, o da un apposito demone, \cmd{klogd}, che estrae i
676 messaggi del kernel.\footnote{i messaggi del kernel sono tenuti in un buffer
677 circolare e scritti tramite la funzione \func{printk}, analoga alla
678 \func{printf} usata in user space; una trattazione eccellente dell'argomento
679 si trova in \cite{LinDevDri}, nel quarto capitolo.}
681 Il servizio permette poi di trattare i vari messaggi classificandoli
682 attraverso due indici; il primo, chiamato \textit{facility}, suddivide in
683 diverse categorie i vari demoni in modo di raggruppare i messaggi provenienti
684 da operazioni che hanno attinenza fra loro, ed è organizzato in sottosistemi
685 (kernel, posta elettronica, demoni di stampa, ecc.). Il secondo, chiamato
686 \textit{priority}, identifica l'importanza dei vari messaggi, e permette di
687 classificarli e differenziare le modalità di notifica degli stessi.
689 Il sistema di \textit{syslog} attraverso \cmd{syslogd} provvede poi a
690 riportare i messaggi all'amministratore attraverso una serie differenti
693 \item scrivere sulla console.
694 \item inviare via mail ad uno specifico utente.
695 \item scrivere su un file (comunemente detto \textit{log file}).
696 \item inviare ad un altro demone (anche via rete).
699 secondo le modalità che questo preferisce e che possono essere impostate
700 attraverso il file di configurazione \file{/etc/syslog.conf} (maggiori
701 dettagli si possono trovare sulle pagine di manuale per questo file e per
704 Le \acr{glibc} definiscono una serie di funzioni standard con cui un processo
705 può accedere in maniera generica al servizio di \textit{syslog}, che però
706 funzionano solo localmente; se si vogliono inviare i messaggi ad un'altro
707 sistema occorre farlo esplicitamente con un socket UDP, o utilizzare le
708 capacità di reinvio del servizio.
710 La prima funzione definita dall'interfaccia è \func{openlog}, che apre una
711 connessione al servizio di \textit{syslog}; essa in generale non è necessaria
712 per l'uso del servizio, ma permette di impostare alcuni valori che controllano
713 gli effetti delle chiamate successive; il suo prototipo è:
714 \begin{prototype}{syslog.h}{void openlog(const char *ident, int option,
717 Apre una connessione al sistema di \textit{syslog}.
719 \bodydesc{La funzione non restituisce nulla.}
722 La funzione permette di specificare, tramite \param{ident}, l'identità di chi
723 ha inviato il messaggio (di norma si passa il nome del programma, come
724 specificato da \code{argv[0]}); la stringa verrà preposta all'inizio di ogni
725 messaggio. Si tenga presente che il valore di \param{ident} che si passa alla
726 funzione è un puntatore, se la stringa cui punta viene cambiata lo sarà pure
727 nei successivi messaggi, e se viene cancellata i risultati potranno essere
728 impredicibili, per questo è sempre opportuno usare una stringa costante.
730 L'argomento \param{facility} permette invece di preimpostare per le successive
731 chiamate l'omonimo indice che classifica la categoria del messaggio.
732 L'argomento è interpretato come una maschera binaria, e pertanto è possibile
733 inviare i messaggi su più categorie alla volta; i valori delle costanti che
734 identificano ciascuna categoria sono riportati in
735 \tabref{tab:sess_syslog_facility}, il valore di \param{facility} deve essere
736 specificato con un OR aritmetico.
741 \begin{tabular}[c]{|l|p{8cm}|}
743 \textbf{Valore}& \textbf{Significato}\\
746 \macro{LOG\_AUTH} & Messaggi relativi ad autenticazione e sicurezza,
747 obsoleto, è sostituito da \macro{LOG\_AUTHPRIV}. \\
748 \macro{LOG\_AUTHPRIV} & Sostituisce \macro{LOG\_AUTH}.\\
749 \macro{LOG\_CRON} & Messaggi dei demoni di gestione dei comandi
750 programmati (\cmd{cron} e \cmd{at}).\\
751 \macro{LOG\_DAEMON} & Demoni di sistema.\\
752 \macro{LOG\_FTP} & Server FTP.\\
753 \macro{LOG\_KERN} & Messaggi del kernel\\
754 \macro{LOG\_LOCAL0} & Riservato all'amministratore per uso locale\\
756 \macro{LOG\_LOCAL7} & Riservato all'amministratore per uso locale\\
757 \macro{LOG\_LPR} & Messaggi del sistema di gestione delle stampanti \\
758 \macro{LOG\_MAIL} & Messaggi del sistema di posta elettronica\\
759 \macro{LOG\_NEWS} & Messaggi del sistema di gestione delle news
761 \macro{LOG\_SYSLOG} & Messaggi generati dallo stesso \cmd{syslogd}\\
762 \macro{LOG\_USER} & Messaggi generici a livello utente\\
763 \macro{LOG\_UUCP} & Messaggi del sistema UUCP\\
766 \caption{Valori possibili per l'argomento \param{facility} di \func{openlog}.}
767 \label{tab:sess_syslog_facility}
770 L'argomento \param{option} serve invece per controllare il comportamento della
771 funzione \func{openlog} e delle modalità con cui le successive chiamate
772 scriveranno i messaggi, esso viene specificato come maschera binaria composta
773 con un OR aritmetico di una qualunque delle costanti riportate in
774 \tabref{tab:sess_openlog_option}.
779 \begin{tabular}[c]{|l|p{8cm}|}
781 \textbf{Valore}& \textbf{Significato}\\
784 \macro{LOG\_CONS} & Scrive sulla console quando. \\
785 \macro{LOG\_NDELAY} & Sostituisce \macro{LOG\_AUTH}.\\
786 \macro{LOG\_NOWAIT} & Messaggi dei demoni di gestione dei comandi
787 programmati (\cmd{cron} e \cmd{at}).\\
788 \macro{LOG\_ODELAY} & .\\
789 \macro{LOG\_PERROR} & Stampa anche su \file{stderr}.\\
790 \macro{LOG\_PID} & Inserisce nei messaggi il \acr{pid} del processo
794 \caption{Valori possibili per l'argomento \param{option} di \func{openlog}.}
795 \label{tab:sess_openlog_option}
798 La funzione che si usa per generare un messaggio è \func{syslog}, dato che
799 l'uso di \func{openlog} è opzionale, sarà quest'ultima a provvede a chiamare la
800 prima qualora ciò non sia stato fatto (nel qual caso il valore di
801 \param{ident} è nullo). Il suo prototipo è:
802 \begin{prototype}{syslog.h}
803 {void syslog(int priority, const char *format, ...)}
805 Genera un messaggio di priorità \param{priority}.
807 \bodydesc{La funzione non restituisce nulla.}
810 Il comportamento della funzione è analogo quello di \func{printf}, e il valore
811 dell'argomento \param{format} è identico a quello descritto nella pagina di
812 manuale di quest'ultima (per i valori principali si può vedere la trattazione
813 sommaria che se ne è fatto in \secref{sec:file_formatted_io}); l'unica
814 differenza è che la sequenza \cmd{\%m} viene rimpiazzata dalla stringa
815 restituita da \code{strerror(errno)}. Gli argomenti seguenti i primi due
816 devono essere forniti secondo quanto richiesto da \func{format}.
818 L'argomento \param{priority} permette di impostare sia la \textit{facility}
819 che la \textit{priority} del messaggio. In realtà viene prevalentemente usato
820 per specificare solo quest'ultima in quanto la prima viene di norma
821 preimpostata con \func{openlog}. La priorità è indicata con un valore
822 numerico\footnote{le \acr{glibc}, seguendo POSIX.1-2001, prevedono otto
823 diverse priorità ordinate da 0 a 7, in ordine di importanza decrescente;
824 questo comporta che i tre bit meno significativi dell'argomento
825 \param{priority} sono occupati da questo valore, mentre i restanti bit più
826 significativi vengono usati per specificare la \textit{facility}.}
827 specificabile attraverso le costanti riportate in
828 \secref{tab:sess_syslog_priority}. Nel caso si voglia specificare anche la
829 \textit{facility} basta eseguire un OR aritmetico del valore della priorità
830 con la maschera binaria delle costanti di \tabref{tab:sess_syslog_facility}.
835 \begin{tabular}[c]{|l|p{8cm}|}
837 \textbf{Valore}& \textbf{Significato}\\
840 \macro{LOG\_EMERG} & Il sistema è inutilizzabile. \\
841 \macro{LOG\_ALERT} & C'è una emergenza che richiede intervento
843 \macro{LOG\_CRIT} & Si è in una condizione critica.\\
844 \macro{LOG\_ERR} & Si è in una condizione di errore.\\
845 \macro{LOG\_WARNING} & Messaggio di avvertimento.\\
846 \macro{LOG\_NOTICE} & Notizia significativa relativa al comportamento.\\
847 \macro{LOG\_INFO} & Messaggio informativo. \\
848 \macro{LOG\_DEBUG} & Messaggio di debug.\\
851 \caption{Valori possibili per l'indice di importanza del messaggio da
852 specificare nell'argomento \param{priority} di \func{syslog}.}
853 \label{tab:sess_syslog_priority}
856 Una ulteriore funzione, \func{setlogmask}, permette di filtrare
857 preliminarmente i messaggi in base alla loro priorità; il suo prototipo è:
858 \begin{prototype}{syslog.h}
859 {int setlogmask(int mask)}
861 Imposta la maschera dei log al valore specificato.
863 \bodydesc{La funzione restituisce il precedente valore.}
866 Le routine di gestione mantengono per ogni processo una maschera che
867 determina quale delle chiamate effettuate a \func{syslog} verrà
868 effettivamente registrata. La registrazione viene disabilitata per tutte
869 quelle priorità che non rientrano nella maschera; questa viene settata
870 usando la macro \code{LOG\_MASK(p)} dove \code{p} è una delle costanti di
871 \secref{tab:sess_syslog_priority}. É inoltre disponibile anche la macro
872 \code{LOG\_UPTO(p)} che permette di specificare automaticamente tutte le
873 priorità fino ad un certo valore.
877 \section{L'I/O su terminale}
878 \label{sec:sess_terminal_io}
880 Benché come ogni altro dispositivo i terminali siano accessibili come file,
881 essi hanno assunto storicamente (essendo stati a lungo l'unico modo di
882 accedere al sistema) una loro rilevanza specifica, che abbiamo già avuto modo
883 di incontrare nella precedente sezione.
885 Esamineremo qui le peculiarità dell'I/O eseguito sui terminali, che per la
886 loro particolare natura presenta delle differenze rispetto ai normali file su
887 disco e agli altri dispositivi.
891 \subsection{L'architettura}
892 \label{sec:term_design}
894 I terminali sono una classe speciale di dispositivi a caratteri (si ricordi la
895 classificazione di \secref{sec:file_file_types}); un terminale ha infatti una
896 caratteristica che lo contraddistingue da un qualunque altro dispositivo, e
897 cioè che è destinato a gestire l'interazione con un utente (deve essere cioè
898 in grado di fare da terminale di controllo per una sessione), che comporta la
899 presenza di ulteriori capacità.
901 L'interfaccia per i terminali è una delle più oscure e complesse, essendosi
902 stratificata dagli inizi dei sistemi Unix fino ad oggi. Questo comporta una
903 grande quantità di opzioni e controlli relativi ad un insieme di
904 caratteristiche (come ad esempio la velocità della linea) necessarie per
905 dispositivi, come i terminali seriali, che al giorno d'oggi sono praticamente
908 Storicamente i primi terminali erano appunto terminali di telescriventi
909 (\textit{teletype}), da cui deriva sia il nome dell'interfaccia, \textit{TTY},
910 che quello dei relativi file di dispositivo, che sono sempre della forma
911 \texttt{/dev/tty*}.\footnote{ciò vale solo in parte per i terminali virtuali,
912 essi infatti hanno due lati, un \textit{master}, che può assumere i nomi
913 \file{/dev/pty[p-za-e][0-9a-f]} ed un corrispondente \textit{slave} con nome
914 \file{/dev/tty[p-za-e][0-9a-f]}.} Oggi essi includono le porte seriali, le
915 console virtuali dello schermo, i terminali virtuali che vengono creati come
916 canali di comunicazione dal kernel e che di solito vengono associati alle
917 connessioni di rete (ad esempio per trattare i dati inviati con \cmd{telnet} o
920 L'I/O sui terminali si effettua con le stesse modalità dei file normali: si
921 apre il relativo file di dispositivo, e si leggono e scrivono i dati con le
922 usuali funzioni di lettura e scrittura, così se apriamo una console virtuale
923 avremo che \func{read} leggerà quanto immesso dalla tastiera, mentre
924 \func{write} scriverà sullo schermo. In realtà questo è vero solo a grandi
925 linee, perché non tiene conto delle caratteristiche specifiche dei terminali;
926 una delle principali infatti è che essi prevedono due modalità di operazione,
927 dette rispettivamente \textsl{modo canonico} e \textsl{modo non canonico}, che
928 comportano dei comportamenti nettamente diversi.
930 La modalità preimpostata all'apertura del terminale è quella canonica, in cui
931 le operazioni di lettura vengono sempre effettuate assemblando i dati in una
932 linea;\footnote{per cui eseguendo una \func{read} su un terminale in modo
933 canonico la funzione si bloccherà, anche se si sono scritti dei caratteri,
934 fintanto che non si preme il tasto di ritorno a capo: a questo punto la
935 linea sarà completa e la funzione ritornerà.} ed in cui alcuni caratteri
936 vengono interpretati per compiere operazioni (come la generazione dei segnali
937 illustrati in \secref{sec:sig_job_control}), questa di norma è la modalità in
938 cui funziona la shell.
940 Un terminale in modo non canonico invece non effettua nessun accorpamento dei
941 dati in linee né li interpreta; esso viene di solito usato dai programmi (gli
942 editor ad esempio) che necessitano di poter leggere un carattere alla volta e
943 che gestiscono al loro interno i vari comandi.
945 Per capire le caratteristiche dell'I/O sui terminali, occorre esaminare le
946 modalità con cui esso viene effettuato; l'accesso, come per tutti i
947 dispositivi, viene gestito da un driver apposito, la cui struttura generica è
948 mostrata in \secref{fig:term_struct}. Ad un terminale sono sempre associate
949 due code per gestire l'input e l'output, che ne implementano una
950 bufferizzazione\footnote{completamente indipendente dalla eventuale ulteriore
951 bufferizzazione fornita dall'interfaccia standard dei file.} all'interno del
955 \centering \includegraphics[width=13cm]{img/term_struct}
956 \caption{Struttura interna generica di un driver per un terminale.}
957 \label{fig:term_struct}
960 La coda di ingresso mantiene i caratteri che sono stati letti dal terminale ma
961 non ancora letti da un processo, la sua dimensione è definita dal parametro di
962 sistema \macro{MAX\_INPUT} (si veda \secref{sec:sys_file_limits}), che ne
963 specifica il limite minimo, in realtà la coda può essere più grande e cambiare
964 dimensione dinamicamente. Se è stato abilitato il controllo di flusso in
965 ingresso il driver emette i caratteri di STOP e START per bloccare e sbloccare
966 l'ingresso dei dati; altrimenti i caratteri immessi oltre le dimensioni
967 massime vengono persi; in alcuni casi il driver provvede ad inviare
968 automaticamente un avviso (un carattere di BELL, che provoca un beep)
969 sull'output quando si eccedono le dimensioni della coda. Se è abilitato il
970 modo canonico i caratteri in ingresso restano nella coda fintanto che non
971 viene ricevuto un a capo; un'altra parametro del sistema, \macro{MAX\_CANON},
972 specifica la dimensione massima di una riga in modo canonico.
974 La coda di uscita è analoga a quella di ingresso e contiene i caratteri
975 scritti dai processi ma non ancora inviati al terminale. Se è abilitato il
976 controllo di flusso in uscita il driver risponde ai caratteri di START e STOP
977 inviati dal terminale. Le dimensioni della coda non sono specificate, ma non
978 hanno molta importanza, in quanto qualora esse vengano eccedute il driver
979 provvede automaticamente a bloccare la funzione chiamante.
983 \subsection{La gestione delle caratteristiche di un terminale}
984 \label{sec:term_attr}
986 Data le loro peculiarità, fin dall'inizio si è posto il problema di come
987 gestire le caratteristiche specifiche dei terminali; storicamente i vari
988 dialetti di Unix hanno utilizzato diverse funzioni, alla fine con POSIX.1, è
989 stata effettuata una standardizzazione, unificando le differenze fra BSD e
990 System V in una unica interfaccia, che è quella usata dal Linux.
992 Alcune di queste funzioni prendono come argomento un file descriptor (in
993 origine molte operazioni venivano effettuate con \func{ioctl}), ma ovviamente
994 possono essere usate solo con file che corrispondano effettivamente ad un
995 terminale (altrimenti si otterrà un errore di \macro{ENOTTY}); questo può
996 essere evitato utilizzando la funzione \func{isatty}, il cui prototipo è:
997 \begin{prototype}{unistd.h}{int isatty(int desc)}
999 Controlla se il file descriptor \param{desc} è un terminale.
1001 \bodydesc{La funzione restituisce 1 se \param{desc} è connesso ad un
1002 terminale, 0 altrimenti.}
1005 Un'altra funzione che fornisce informazioni su un terminale è \func{ttyname},
1006 che permette di ottenere il nome del terminale associato ad un file
1007 descriptor; il suo prototipo è:
1008 \begin{prototype}{unistd.h}{char *ttyname(int desc)}
1010 Restituisce il nome del terminale associato al file \param{desc}.
1012 \bodydesc{La funzione restituisce il puntatore alla stringa contenente il
1013 nome del terminale associato \param{desc} e \macro{NULL} in caso di
1017 Si tenga presente che la funzione restituisce un indirizzo di dati statici,
1018 che pertanto possono essere sovrascritti da successive chiamate. Una funzione
1019 funzione analoga, anch'essa prevista da POSIX.1, è \func{ctermid}, il cui
1021 \begin{prototype}{stdio.h}{char *ctermid(char *s)}
1023 Restituisce il nome del terminale di controllo del processo.
1025 \bodydesc{La funzione restituisce il puntatore alla stringa contenente il
1026 pathname del terminale.}
1029 La funzione scrive il pathname del terminale di controllo del processo
1030 chiamante nella stringa posta all'indirizzo specificato dall'argomento
1031 \param{s}. La memoria per contenere la stringa deve essere stata allocata in
1032 precedenza ed essere lunga almeno
1033 \macro{L\_ctermid}\footnote{\macro{L\_ctermid} è una delle varie costanti del
1034 sistema, non trattata esplicitamente in \secref{sec:sys_characteristics} che
1035 indica la dimensione che deve avere una stringa per poter contenere il nome
1036 di un terminale.} caratteri.
1038 Esiste infine una versione rientrante \func{ttyname\_r} della funzione
1039 \func{ttyname}, che non presenta il problema dell'uso di una zona di memoria
1040 statica; il suo prototipo è:
1041 \begin{prototype}{unistd.h}{int ttyname\_r(int desc, char *buff, size\_t len)}
1043 Restituisce il nome del terminale associato al file \param{desc}.
1045 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1046 errore, nel qual caso \var{errno} assumerà i valori:
1048 \item[\macro{ERANGE}] la lunghezza del buffer, \param{len}, non è
1049 sufficiente per contenere la stringa restituita.
1051 ed inoltre \macro{EBADF} ed \macro{ENOSYS}.
1055 La funzione prende due argomenti, il puntatore alla zona di memoria
1056 \param{buff}, in cui l'utente vuole che il risultato venga scritto (dovrà
1057 ovviamente essere stata allocata in precedenza), e la relativa dimensione,
1058 \param{len}; se la stringa che deve essere restituita eccede questa dimensione
1059 si avrà una condizione di errore.
1061 Se si passa come argomento \macro{NULL} la funzione restituisce il puntatore
1062 ad una stringa statica che può essere sovrascritta da chiamate successive. Si
1063 tenga presente che il pathname restituito potrebbe non identificare
1064 univocamente il terminale (ad esempio potrebbe essere \file{/dev/tty}),
1065 inoltre non è detto che il processo possa effettivamente aprire il terminale.
1067 I vari attributi vengono mantenuti per ciascun terminale in una struttura
1068 \var{termios}, (la cui definizione è riportata in \figref{fig:term_termios}),
1069 usata dalle varie funzioni dell'interfaccia. In \figref{fig:term_termios} si
1070 sono riportati tutti i campi della definizione usata in Linux; di questi solo
1071 i primi cinque sono previsti dallo standard POSIX.1, ma le varie
1072 implementazioni ne aggiungono degli altri per mantenere ulteriori
1073 informazioni.\footnote{la definizione della struttura si trova in
1074 \file{bits/termios.h}, da non includere mai direttamente, Linux, seguendo
1075 l'esempio di BSD, aggiunge i due campi \var{c\_ispeed} e \var{c\_ospeed} per
1076 mantenere le velocità delle linee seriali, ed un campo ulteriore,
1077 \var{c\_line} per ... (NdT, trovare a che serve}.}
1079 \begin{figure}[!htb]
1080 \footnotesize \centering
1081 \begin{minipage}[c]{15cm}
1082 \begin{lstlisting}[labelstep=0]{}
1084 tcflag_t c_iflag; /* input modes */
1085 tcflag_t c_oflag; /* output modes */
1086 tcflag_t c_cflag; /* control modes */
1087 tcflag_t c_lflag; /* local modes */
1088 cc_t c_cc[NCCS]; /* control characters */
1089 cc_t c_line; /* line discipline */
1090 speed_t c_ispeed; /* input speed */
1091 speed_t c_ospeed; /* output speed */
1096 \caption{La struttura \var{termios}, che identifica le proprietà di un
1098 \label{fig:term_termios}
1101 I primi quattro campi sono quattro flag che controllano il comportamento del
1102 terminale; essi sono realizzati come maschera binaria, pertanto il tipo
1103 \type{tcflag\_t} è di norma realizzato con un intero senza segno di lunghezza
1104 opportuna. I valori devono essere specificati bit per bit, avendo cura di non
1105 modificare i bit su cui non si interviene.
1110 \begin{tabular}[c]{|l|p{11cm}|}
1112 \textbf{Valore}& \textbf{Significato}\\
1115 \macro{INPCK} & Abilita il controllo di parità in ingresso. Se non viene
1116 impostato non viene fatto nessun controllo ed i caratteri
1117 vengono passati in input direttamente.\\
1118 \macro{IGNPAR} & Ignora gli errori di parità, il carattere viene passato
1119 come ricevuto. Ha senso solo se si è impostato
1121 \macro{PARMRK} & Controlla come vengono riportati gli errori di parità. Ha
1122 senso solo se \macro{INPCK} è impostato e \macro{IGNPAR}
1123 no. Se impostato inserisce una sequenza \texttt{0xFF
1124 0x00} prima di ogni carattere che presenta errori di
1125 parità, se non impostato un carattere con errori di
1126 parità viene letto come uno \texttt{0x00}. Se un
1127 carattere ha il valore \texttt{0xFF} e \macro{ISTRIP}
1128 non è settato, per evitare ambiguità esso viene sempre
1129 riportato come \texttt{0xFF 0xFF}.\\
1130 \macro{ISTRIP} & Se impostato i caratteri in input sono tagliati a sette
1131 bit mettendo a zero il bit più significativo, altrimenti
1132 vengono passati tutti gli otto bit.\\
1133 \macro{IGNBRK} & Ignora le condizioni di BREAK sull'input. Una
1134 \textit{condizione di BREAK} è definita nel contesto di
1135 una trasmissione seriale asincrona come una sequenza di
1136 bit nulli più lunga di un byte. \\
1137 \macro{BRKINT} & Controlla la reazione ad un BREAK quando
1138 \macro{IGNBRK} non è impostato. Se \macro{BRKINT} è
1139 impostato il BREAK causa lo scarico delle code,
1140 e se il terminale è il terminale di controllo per un
1141 gruppo in foreground anche l'invio di \macro{SIGINT} ai
1142 processi di quest'ultimo. Se invece \macro{BRKINT} non è
1143 impostato un BREAK viene letto come un carattere
1144 NUL, a meno che non sia settato \macro{PARMRK}
1145 nel qual caso viene letto come la sequenza di caratteri
1146 \texttt{0xFF 0x00 0x00}.\\
1147 \macro{IGNCR} & Se impostato il carattere di ritorno carrello
1148 (\textit{carriage return}, \verb|'\r'|) viene scartato
1149 dall'input. Può essere utile per i terminali che inviano
1150 entrambi i caratteri di ritorno carrello e a capo
1151 (\textit{newline}, \verb|'\n'|). \\
1152 \macro{ICRNL} & Se impostato un carattere di ritorno carrello
1153 (\verb|'\r'|) sul terminale viene automaticamente
1154 trasformato in un a capo (\verb|'\n'|) sulla coda di
1156 \macro{INLCR} & Se impostato il carattere di a capo
1157 (\verb|'\n'|) viene automaticamente trasformato in un
1158 ritorno carrello (\verb|'\r'|).\\
1159 \macro{IUCLC} & Se impostato trasforma i caratteri maiuscoli dal
1160 terminale in minuscoli sull'ingresso (opzione non
1162 \macro{IXON} & Se impostato attiva il controllo di flusso in uscita con i
1163 caratteri di START e STOP. se si riceve
1164 uno STOP l'output viene bloccato, e viene fatto
1165 ripartire solo da uno START, e questi due
1166 caratteri non vengono passati alla coda di input. Se non
1167 impostato i due caratteri sono passati alla coda di input
1168 insieme agli altri.\\
1169 \macro{IXANY} & Se impostato con il controllo di flusso permette a
1170 qualunque carattere di far ripartire l'output bloccato da
1171 un carattere di STOP.\\
1172 \macro{IXOFF} & Se impostato abilita il controllo di flusso in
1173 ingresso. Il computer emette un carattere di STOP per
1174 bloccare l'input dal terminale e lo sblocca con il
1176 \macro{IMAXBEL}& Se impostato fa suonare il cicalino se si riempie la cosa
1177 di ingresso; in Linux non è implementato e il kernel si
1178 comporta cose se fosse sempre settato (è una estensione
1182 \caption{Costanti identificative dei vari bit del flag di controllo
1183 \var{c\_iflag} delle modalità di input di un terminale.}
1184 \label{tab:sess_termios_iflag}
1187 Il primo flag, mantenuto nel campo \var{c\_iflag}, è detto \textsl{flag di
1188 input} e controlla le modalità di funzionamento dell'input dei caratteri sul
1189 terminale, come il controllo di parità, il controllo di flusso, la gestione
1190 dei caratteri speciali; un elenco dei vari bit, del loro significato e delle
1191 costanti utilizzate per identificarli è riportato in
1192 \tabref{tab:sess_termios_iflag}.
1194 Si noti come alcuni di questi flag (come quelli per la gestione del flusso)
1195 fanno riferimento a delle caratteristiche che ormai sono completamente
1196 obsolete; la maggior parte inoltre è tipica di terminali seriali, e non ha
1197 alcun effetto su dispositivi diversi come le console virtuali o gli
1198 pseudo-terminali usati nelle connessioni di rete.
1203 \begin{tabular}[c]{|l|p{11cm}|}
1205 \textbf{Valore}& \textbf{Significato}\\
1208 \macro{OPOST} & Se impostato i caratteri vengono convertiti opportunamente
1209 (in maniera dipendente dall'implementazione) per la
1210 visualizzazione sul terminale, ad esempio al
1211 carattere di a capo (NL) può venire aggiunto un ritorno
1213 \macro{OCRNL} & Se impostato converte automaticamente il carattere di a
1214 capo (NL) nella coppia di caratteri ritorno carrello, a
1216 \macro{OLCUC} & Se impostato trasforma i caratteri minuscoli in ingresso
1217 in caratteri maiuscoli sull'uscita (non previsto da
1219 \macro{ONLCR} & Se impostato converte automaticamente il carattere di a
1220 capo (NL) in un carattere di ritorno carrello (CR).\\
1221 \macro{ONOCR} & Se impostato converte il carattere di ritorno carrello
1222 (CR) nella coppia di caratteri CR-NL.\\
1223 \macro{ONLRET}& Se impostato rimuove dall'output il carattere di ritorno
1225 \macro{OFILL} & Se impostato in caso di ritardo sulla linea invia dei
1226 caratteri di riempimento invece di attendere.\\
1227 \macro{OFDEL} & Se impostato il carattere di riempimento è DEL
1228 (\texttt{0x3F}), invece che NUL (\texttt{0x00}).\\
1229 \macro{NLDLY} & Maschera per i bit che indicano il ritardo per il
1230 carattere di a capo (NL), i valori possibili sono
1231 \macro{NL0} o \macro{NL1}.\\
1232 \macro{CRDLY} & Maschera per i bit che indicano il ritardo per il
1233 carattere ritorno carrello (CR), i valori possibili sono
1234 \macro{CR0}, \macro{CR1}, \macro{CR2} o \macro{CR3}.\\
1235 \macro{TABDLY}& Maschera per i bit che indicano il ritardo per il
1236 carattere di tabulazione, i valori possibili sono
1237 \macro{TAB0}, \macro{TAB1}, \macro{TAB2} o \macro{TAB3}.\\
1238 \macro{BSDLY} & Maschera per i bit che indicano il ritardo per il
1239 carattere di ritorno indietro (\textit{backspace}), i
1240 valori possibili sono \macro{BS0} o \macro{BS1}.\\
1241 \macro{VTDLY} & Maschera per i bit che indicano il ritardo per il
1242 carattere di tabulazione verticale, i valori possibili sono
1243 \macro{VT0} o \macro{VT1}.\\
1244 \macro{FFDLY} & Maschera per i bit che indicano il ritardo per il
1245 carattere di pagina nuova (\textit{form feed}), i valori
1246 possibili sono \macro{FF0} o \macro{FF1}.\\
1249 \caption{Costanti identificative dei vari bit del flag di controllo
1250 \var{c\_oflag} delle modalità di output di un terminale.}
1251 \label{tab:sess_termios_oflag}
1254 Il secondo flag, mantenuto nel campo \var{c\_oflag}, è detto \textsl{flag di
1255 output} e controlla le modalità di funzionamento dell'output dei caratteri,
1256 come l'impacchettamento dei caratteri sullo schermo, la traslazione degli a
1257 capo, la conversione dei caratteri speciali; un elenco dei vari bit, del loro
1258 significato e delle costanti utilizzate per identificarli è riportato in
1259 \tabref{tab:sess_termios_oflag}.
1261 Si noti come alcuni dei valori riportati in \tabref{tab:sess_termios_oflag}
1262 fanno riferimento a delle maschere di bit; essi infatti vengono utilizzati per
1263 impostare alcuni valori numerici relativi ai ritardi nell'output di alcuni
1264 caratteri: una caratteristica originaria dei primi terminali su telescrivente,
1265 che avevano bisogno di tempistiche diverse per spostare il carrello in
1266 risposta ai caratteri speciali, e che oggi sono completamente in disuso.
1268 Si tenga presente inoltre che nel caso delle maschere il valore da inserire in
1269 \var{c\_oflag} deve essere fornito avendo cura di cancellare prima tutti i bit
1270 della maschera, i valori da immettere infatti (quelli riportati nella
1271 spiegazione corrispondente) sono numerici e non per bit, per cui possono
1272 sovrapporsi fra di loro. Occorrerà perciò utilizzare un codice del tipo:
1274 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}%
1275 c_oflag &= (~CRDLY);
1279 \noindent che prima cancella i bit della maschera in questione e poi setta il
1286 \begin{tabular}[c]{|l|p{11cm}|}
1288 \textbf{Valore}& \textbf{Significato}\\
1291 \macro{CLOCAL} & Se impostato indica che il terminale è connesso in locale
1292 e che le linee di controllo del modem devono essere
1293 ignorate. Se non impostato effettuando una chiamata ad
1294 \func{open} senza aver specificato il flag di
1295 \macro{O\_NOBLOCK} si bloccherà il processo finché
1296 non si è stabilita una connessione con il modem; inoltre
1297 se viene rilevata una disconessione viene inviato un
1298 \macro{SIGHUP} al processo di controllo del terminale. La
1299 lettura su un terminale sconnesso comporta una condizione
1300 di \textit{end of file} e la scrittura un errore di
1302 \macro{HUPCL} & Se è impostato viene distaccata la connessione del
1303 modem quando l'ultimo dei processi che ha ancora un file
1304 aperto sul terminale lo chiude o esce.\\
1305 \macro{CREAD} & Se è impostato si può leggere l'input del terminale,
1306 altrimenti i caratteri in ingresso vengono scartati
1308 \macro{CSTOPB} & Se impostato vengono usati due bit di stop sulla linea
1309 seriale, se non impostato ne viene usato soltanto uno.\\
1310 \macro{PARENB} & Se impostato abilita la generazione il controllo di
1311 parità. La reazione in caso di errori dipende dai
1312 relativi valori per \var{c\_iflag}, riportati in
1313 \tabref{tab:sess_termios_iflag}. Se non è impostato i bit
1314 di parità non vengono
1315 generati e i caratteri non vengono controllati.\\
1316 \macro{PARODD} & Ha senso solo se è attivo anche \macro{PARENB}. Se
1317 impostato viene usata una parità è dispari, altrimenti
1318 viene usata una parità pari.\\
1319 \macro{CSIZE} & Maschera per i bit usati per specificare la dimensione
1320 del carattere inviato lungo la linea di trasmissione, i
1321 valore ne indica la lunghezza (in bit), ed i valori
1322 possibili sono \macro{CS5}, \macro{CS6},
1323 \macro{CS7} e \macro{CS8}
1324 corrispondenti ad un analogo numero di bit.\\
1325 \macro{CBAUD} & Maschera dei bit (4+1) usati per impostare della velocità
1326 della linea (il \textit{baud rate}) in ingresso.
1327 In Linux non è implementato in quanto viene
1328 usato un apposito campo di \var{termios}.\\
1329 \macro{CBAUDEX}& Bit aggiuntivo per l'impostazione della velocità della
1330 linea, per le stesse motivazioni del precedente non è
1331 implementato in Linux.\\
1332 \macro{CIBAUD} & Maschera dei bit della velocità della linea in
1333 ingresso. Analogo a \macro{CBAUD}, anch'esso in Linux è
1334 mantenuto in un apposito campo di \var{termios}. \\
1335 \macro{CRTSCTS}& Abilita il controllo di flusso hardware sulla seriale,
1336 attraverso l'utilizzo delle dei due fili di RTS e CTS.\\
1339 \caption{Costanti identificative dei vari bit del flag di controllo
1340 \var{c\_cflag} delle modalità di controllo di un terminale.}
1341 \label{tab:sess_termios_cflag}
1344 Il terzo flag, mantenuto nel campo \var{c\_cflag}, è detto \textsl{flag di
1345 controllo} ed è legato al funzionamento delle linee seriali, permettendo di
1346 impostarne varie caratteristiche, come il numero di bit di stop, i settaggi
1347 della parità, il funzionamento del controllo di flusso; esso ha senso solo per
1348 i terminali connessi a linee seriali. Un elenco dei vari bit, del loro
1349 significato e delle costanti utilizzate per identificarli è riportato in
1350 \tabref{tab:sess_termios_cflag}.
1352 I valori di questo flag sono molto specifici, e completamente indirizzati al
1353 controllo di un terminale mantenuto su una linea seriale; essi pertanto non
1354 hanno nessuna rilevanza per i terminali che usano un'altra interfaccia, come
1355 le console virtuali e gli pseudo-terminali usati dalle connessioni di rete.
1357 Inoltre alcuni valori sono previsti solo per quelle implementazioni (lo
1358 standard POSIX non specifica nulla riguardo l'implementazione, ma solo delle
1359 funzioni di lettura e scrittura) che mantengono le velocità delle linee
1360 seriali all'interno dei flag; come accennato in Linux questo viene fatto
1361 (seguendo l'esempio di BSD) attraverso due campi aggiuntivi, \var{c\_ispeed} e
1362 \var{c\_ospeed}, nella struttura \var{termios} (mostrati in
1363 \figref{fig:term_termios}).
1368 \begin{tabular}[c]{|l|p{11cm}|}
1370 \textbf{Valore}& \textbf{Significato}\\
1373 \macro{ICANON} & Se impostato il terminale opera in modo canonico,
1374 altrimenti opera in modo non canonico.\\
1375 \macro{ECHO} & Se è impostato viene attivato l'eco dei caratteri in
1376 input sull'output del terminale.\\
1377 \macro{ECHOE} & Se è impostato l'eco mostra la cancellazione di un
1378 carattere in input (in reazione al carattere ERASE)
1379 cancellando l'ultimo carattere della riga corrente dallo
1380 schermo; altrimenti il carattere è rimandato in eco per
1381 mostrare quanto accaduto (usato per i terminali con
1382 l'uscita su una stampante). \\
1383 \macro{ECHOPRT}& Se impostato abilita la visualizzazione del carattere di
1384 cancellazione in una modalità adatta ai terminali con
1385 l'uscita su stampante; l'invio del carattere di ERASE
1386 comporta la stampa di un \verb|\| seguito dal carattere
1387 cancellato, e così via in caso di successive
1388 cancellazioni, quando si riprende ad immettere carattere
1389 normali prima verrà stampata una \texttt{/}.\\
1390 \macro{ECHOK} & Se impostato abilita il trattamento della visualizzazione
1391 del carattere KILL, andando a capo dopo aver visualizzato
1392 lo stesso, altrimenti viene solo mostrato il carattere e
1393 sta all'utente ricordare che l'input precedente è stato
1395 \macro{ECHOKE} & Se impostato abilita il trattamento della visualizzazione
1396 del carattere KILL cancellando i caratteri precedenti
1397 nella linea secondo le modalità specificate dai valori di
1398 \macro{ECHOE} e \macro{ECHOPRT}.\\
1399 \macro{ECHONL} & Se impostato viene effettuato l'eco di un a
1400 capo (\verb|\n|) anche se non è stato impostato
1402 \macro{ECHOCTL}& Se impostato insieme ad \macro{ECHO} i caratteri di
1403 controllo ASCII (tranne TAB, NL, START, e STOP) sono
1404 mostrati nella forma che prepende un \verb|^| alla
1405 lettera ottenuta sommando \texttt{0x40} al valore del
1406 carattere (di solito questi si possono ottenere anche
1407 direttamente premendo il tasto \texttt{ctrl} più la
1408 relativa lettera).\\
1409 \macro{ISIG} & Se impostato abilita il riconoscimento dei caratteri
1410 INTR, QUIT, e SUSP generando il relativo segnale.\\
1411 \macro{IEXTEN} & Abilita alcune estensioni previste dalla
1412 implementazione. Deve essere impostato perché caratteri
1413 speciali come EOL2, LNEXT, REPRINT e WERASE possano
1414 essere interpretati. \\
1415 \macro{NOFLSH} & Se impostato disabilita lo scarico delle code di ingresso
1416 e uscita quando vengono emessi i segnali \macro{SIGINT},
1417 \macro{SIGQUIT} and \macro{SIGSUSP}.\\
1418 \macro{TOSTOP} & Se abilitato, con il supporto per il job control presente,
1419 genera il segnale \macro{SIGTTOU} per un processo in
1420 background che cerca di scrivere sul terminale.\\
1421 \macro{XCASE} & Se settato il terminale funziona solo con le
1422 maiuscole. L'input è convertito in minuscole tranne per i
1423 caratteri preceduti da una \verb|\|. In output le
1424 maiuscole sono precedute da una \verb|\| e le minuscole
1425 convertite in maiuscole.\\
1426 \macro{DEFECHO}& Se impostate effettua l'eco solo se c'è un processo in
1428 \macro{FLUSHO} & Effettua la cancellazione della coda di uscita. Viene
1429 attivato dal carattere DISCARD. Non è supportato in
1431 \macro{PENDIN} & Indica che la linea deve essere ristampata, viene
1432 attivato dal carattere REPRINT e resta attivo fino alla
1433 fine della ristampa. Non è supportato in Linux.\\
1436 \caption{Costanti identificative dei vari bit del flag di controllo
1437 \var{c\_lflag} delle modalità locali di un terminale.}
1438 \label{tab:sess_termios_lflag}
1441 Il quarto flag, mantenuto nel campo \var{c\_lflag}, è detto \textsl{flag
1442 locale}, e serve per controllare il funzionamento dell'interfaccia fra il
1443 driver e l'utente, come abilitare l'eco, gestire i caratteri di controllo e
1444 l'emissione dei segnali, impostare modo canonico o non canonico; un elenco dei
1445 vari bit, del loro significato e delle costanti utilizzate per identificarli è
1446 riportato in \tabref{tab:sess_termios_lflag}. Con i terminali odierni l'unico
1447 flag con cui probabilmente si può avere a che fare è questo, in quanto è con
1448 questo che si impostano le caratteristiche generiche comuni a tutti i
1451 Si tenga presente che i flag che riguardano le modalità di eco dei caratteri
1452 (\macro{ECHOE}, \macro{ECHOPRT}, \macro{ECHOK}, \macro{ECHOKE},
1453 \macro{ECHONL}) controllano solo il comportamento della visualizzazione, il
1454 riconoscimento dei vari caratteri dipende dalla modalità di operazione, ed
1455 avviene solo in modo canonico, pertanto questi flag non hanno significato se
1456 non è impostato \macro{ICANON}.
1458 Oltre ai vari flag per gestire le varie caratteristiche dei terminali,
1459 \var{termios} contiene pure il campo \var{c\_cc} che viene usato per impostare
1460 i caratteri speciali associati alle varie funzioni di controllo. Il numero di
1461 questi caratteri speciali è indicato dalla costante \macro{NCCS}, POSIX ne
1462 specifica almeno 11, ma molte implementazioni ne definiscono molti
1463 altri.\footnote{in Linux il valore della costante è 32, anche se i caratteri
1464 effettivamente definiti sono solo 17.}
1469 \begin{tabular}[c]{|l|c|c|p{8cm}|}
1471 \textbf{Indice} & \textbf{Valore}&\textbf{Codice} & \textbf{Funzione}\\
1474 \macro{VINTR} &\texttt{0x03}&(\verb|C-c|)& Carattere di interrupt,
1475 provoca l'emissione di
1477 \macro{VQUIT} &\texttt{0x1C}&(\verb|C-\|)& Carattere di uscita provoca
1480 \macro{VERASE} &\texttt{0x7f}& DEL & Carattere di ERASE, cancella
1481 l'ultimo carattere precedente
1483 \macro{VKILL} &\texttt{0x15}&(\verb|C-u|)& Carattere di KILL, cancella
1485 \macro{VEOF} &\texttt{0x04}&(\verb|C-d|)& Carattere di
1486 \textit{end-of-file}. Causa
1487 l'invio del contenuto del
1488 buffer di ingresso al
1489 processo in lettura anche se
1490 non è ancora stato ricevuto
1491 un a capo. Se è il primo
1492 carattere immesso comporta il
1493 ritorno di \func{read} con
1494 zero caratteri, cioè la
1496 \textit{end-of-file}.\\
1497 \macro{VTIME} & --- & --- & Timeout, in decimi di secondo, per
1498 una lettura in modo non canonico. \\
1499 \macro{VMIN} & --- & --- & Numero minimo di caratteri per una
1500 lettura in modo non canonico.\\
1501 \macro{VSWTC} &\texttt{0x00}& NUL & Carattere di switch. Non supportato
1503 \macro{VSTART} &\texttt{0x21}&(\verb|C-q|)& Carattere di START. Riavvia un
1504 output bloccato da uno STOP.\\
1505 \macro{VSTOP} &\texttt{0x23}&(\verb|C-s|)& Carattere di STOP. Blocca
1506 l'output fintanto che non
1507 viene premuto un carattere di
1509 \macro{VSUSP} &\texttt{0x1A}&(\verb|C-z|)& Carattere di
1510 sospensione. Invia il segnale
1512 \macro{VEOL} &\texttt{0x00}& NUL & Carattere di fine riga. Agisce come
1513 un a capo, ma non viene scartato ed
1514 è letto come l'ultimo carattere
1516 \macro{VREPRINT}&\texttt{0x12}&(\verb|C-r|)& Ristampa i caratteri non
1518 \macro{VDISCARD}&\texttt{0x07}&(\verb|C-o|)& Non riconosciuto in Linux. \\
1519 \macro{VWERASE} &\texttt{0x17}&(\verb|C-w|)& Cancellazione di una parola.\\
1520 \macro{VLNEXT} &\texttt{0x16}&(\verb|C-v|)& Carattere di escape, serve a
1521 quotare il carattere
1522 successivo che non viene
1523 interpretato ma passato
1524 direttamente all'output. \\
1525 \macro{VEOL2} &\texttt{0x00}& NUL & Ulteriore carattere di fine
1526 riga. Ha lo stesso effetto di
1527 \macro{VEOL} ma può essere un
1528 carattere diverso. \\
1531 \caption{Valori dei caratteri di controllo mantenuti nel campo \var{c\_cc}
1532 della struttura \var{termios}.}
1533 \label{tab:sess_termios_cc}
1537 A ciascuna di queste funzioni di controllo corrisponde un elemento del vettore
1538 \var{c\_cc} che specifica quale è il carattere speciale associato; per
1539 portabilità invece di essere indicati con la loro posizione numerica nel
1540 vettore, i vari elementi vengono indicizzati attraverso delle opportune
1541 costanti, il cui nome corrisponde all'azione ad essi associata. Un elenco
1542 completo dei caratteri di controllo, con le costanti e delle funzionalità
1543 associate è riportato in \tabref{tab:sess_termios_cc}, usando quelle
1544 definizioni diventa possibile assegnare un nuovo carattere di controllo con un
1546 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}%
1547 value.c_cc[VEOL2] = '\n';
1550 La maggior parte di questi caratteri (tutti tranne \macro{VTIME} e
1551 \macro{VMIN}) hanno effetto solo quando il terminale viene utilizzato in modo
1552 canonico; per alcuni devono essere essere soddisfatte ulteriori richieste, ad
1553 esempio \macro{VINTR}, \macro{VSUSP}, e \macro{VQUIT} richiedono sia settato
1554 \macro{ISIG}; \macro{VSTART} e \macro{VSTOP} richiedono sia settato
1555 \macro{IXON}; \macro{VLNEXT}, \macro{VWERASE}, \macro{VREPRINT} richiedono sia
1556 settato \macro{IEXTEN}. In ogni caso quando vengono attivati i caratteri
1557 vengono interpretati e non sono passati sulla coda di ingresso.
1559 Per leggere ed scrivere tutte le impostazioni dei terminali lo standard POSIX
1560 prevede due funzioni, \func{tcgetattr} e \func{tcsetattr}; entrambe utilizzano
1561 come argomento un puntatore ad struttura \var{termios} che sarà quella in cui
1562 andranno immagazzinate le impostazioni, il loro prototipo è:
1565 \headdecl{termios.h}
1566 \funcdecl{int tcgetattr(int fd, struct termios *termios\_p)}
1567 Legge il valore delle impostazioni di un terminale.
1569 \funcdecl{int tcsetattr(int fd, int optional\_actions, struct termios
1571 Scrive le impostazioni di un terminale.
1573 \bodydesc{Entrambe le funzioni restituiscono 0 in caso di successo e -1 in
1574 caso di errore, nel qual caso \var{errno} assumerà i valori:
1576 \item[\macro{EINTR}] La funzione è stata interrotta.
1578 ed inoltre \macro{EBADF}, \macro{ENOTTY} ed \macro{EINVAL}.
1582 Le funzioni operano sul terminale cui fa riferimento il file descriptor
1583 \param{fd} utilizzando la struttura indicata dal puntatore \param{termios\_p}
1584 per lo scambio dei dati. Si tenga presente che le impostazioni sono associate
1585 al terminale e non al file descriptor; questo significa che se si è cambiata
1586 una impostazione un qualunque altro processo che apra lo stesso terminale, od
1587 un qualunque altro file descriptor che vi faccia riferimento, vedrà le nuove
1588 impostazioni pur non avendo nulla a che fare con il file descriptor che si è
1589 usato per effettuare i cambiamenti.
1591 Questo significa che non è possibile usare file descriptor diversi per
1592 utilizzare automaticamente il terminale in modalità diverse, se esiste una
1593 necessità di accesso differenziato di questo tipo occorrerà cambiare
1594 esplicitamente la modalità tutte le volte che si passa da un file descriptor
1597 La funzione \func{tcgetattr} legge i valori correnti delle impostazioni di un
1598 terminale qualunque nella struttura puntata da \param{termios\_p};
1599 \func{tcsetattr} invece effettua la scrittura delle impostazioni e quando
1600 viene invocata sul proprio terminale di controllo può essere eseguita con
1601 successo solo da un processo in foreground. Se invocata da un processo in
1602 background infatti tutto il gruppo riceverà un segnale di \macro{SIGTTOU} come
1603 se si fosse tentata una scrittura, a meno che il processo chiamante non abbia
1604 \macro{SIGTTOU} ignorato o bloccato, nel qual caso l'operazione sarà eseguita.
1606 La funzione \func{tcsetattr} prevede tre diverse modalità di funzionamento,
1607 specificabili attraverso l'argomento \param{optional\_actions}, che permette
1608 di stabilire come viene eseguito il cambiamento delle impostazioni del
1609 terminale, i valori possibili sono riportati in
1610 \tabref{tab:sess_tcsetattr_option}; di norma (come fatto per le due funzioni
1611 di esempio) si usa sempre \macro{TCSANOW}, le altre opzioni possono essere
1612 utili qualora si cambino i parametri di output.
1617 \begin{tabular}[c]{|l|p{8cm}|}
1619 \textbf{Valore}& \textbf{Significato}\\
1622 \macro{TCSANOW} & Esegue i cambiamenti in maniera immediata. \\
1623 \macro{TCSADRAIN}& I cambiamenti vengono eseguiti dopo aver atteso che
1624 tutto l'output presente sulle code è stato scritto. \\
1625 \macro{TCSAFLUSH}& È identico a \macro{TCSADRAIN}, ma in più scarta
1626 tutti i dati presenti sulla coda di input.\\
1629 \caption{Possibili valori per l'argomento \param{optional\_actions} della
1630 funzione \func{tcsetattr}.}
1631 \label{tab:sess_tcsetattr_option}
1634 Occorre infine tenere presente che \func{tcsetattr} ritorna con successo anche
1635 se soltanto uno dei cambiamenti richiesti è stato eseguito. Pertanto se si
1636 effettuano più cambiamenti è buona norma controllare con una ulteriore
1637 chiamata a \func{tcgetattr} che essi siano stati eseguiti tutti quanti.
1639 \begin{figure}[!htb]
1641 \begin{lstlisting}{}%
1643 #include <termios.h>
1646 int SetTermAttr(int fd, tcflag_t flag)
1648 struct termios values;
1650 res = tcgetattr (desc, &values);
1652 perror("Cannot get attributes");
1655 values.c_lflag |= flag;
1656 res = tcsetattr (desc, TCSANOW, &values);
1658 perror("Cannot set attributes");
1664 \caption{Codice della funzione \func{SetTermAttr} che permette di
1665 impostare uno dei flag di controllo locale del terminale.}
1666 \label{fig:term_set_attr}
1669 Come già accennato per i cambiamenti effettuati ai vari flag di controllo
1670 occorre che i valori di ciascun bit siano specificati avendo cura di mantenere
1671 intatti gli altri; per questo motivo in generale si deve prima leggere il
1672 valore corrente delle impostazioni con \func{tcgetattr} per poi modificare i
1675 In \figref{fig:term_set_attr} e \figref{fig:term_unset_attr} si è riportato
1676 rispettivamente il codice delle due funzioni \func{SetTermAttr} e
1677 \func{UnSetTermAttr}, che possono essere usate per impostare o rimuovere, con
1678 le dovute precauzioni, un qualunque bit di \var{c\_lflag}. Il codice di
1679 entrambe le funzioni può essere trovato nel file \file{SetTermAttr.c} dei
1682 La funzione \func{SetTermAttr} provvede ad impostare il bit specificato
1683 dall'argomento \param{flag}; prima si leggono i valori correnti
1684 (\texttt{\small 10}) con \func{tcgetattr}, uscendo con un messaggio in caso di
1685 errore (\texttt{\small 11--14}), poi si provvede a impostare solo i bit
1686 richiesti (possono essere più di uno) con un OR binario (\texttt{\small 15});
1687 infine si scrive il nuovo valore modificato con \func{tcsetattr}
1688 (\texttt{\small 16}), notificando un eventuale errore (\texttt{\small 11--14})
1689 o uscendo normalmente.
1691 \begin{figure}[!htb]
1693 \begin{lstlisting}{}%
1694 int UnSetTermAttr(int fd, tcflag_t flag)
1696 struct termios values;
1698 res = tcgetattr (desc, &values);
1700 perror("Cannot get attributes");
1703 values.c_lflag &= (~flag);
1704 res = tcsetattr (desc, TCSANOW, &values);
1706 perror("Cannot set attributes");
1712 \caption{Codice della funzione \func{UnSetTermAttr} che permette di
1713 rimuovere uno dei flag di controllo locale del terminale.}
1714 \label{fig:term_unset_attr}
1717 La seconda funzione, \func{UnSetTermAttr}, è assolutamente identica alla
1718 prima, solo che in questo caso (in \texttt{\small 15}) si rimuovono i bit
1719 specificati dall'argomento \param{flag} usando un AND binario del valore
1723 Al contrario di tutte le altre caratteristiche dei terminali, che possono
1724 essere impostate esplicitamente utilizzando gli opportuni campi di
1725 \var{termios}, per le velocità della linea (il cosiddetto \textit{baud rate})
1726 non è prevista una implementazione standardizzata, per cui anche se in Linux
1727 sono mantenute in due campi dedicati nella struttura, questi non devono essere
1728 acceduti direttamente ma solo attraverso le apposite funzioni di interfaccia
1729 provviste da POSIX.1.
1731 Lo standard prevede due funzioni per scrivere la velocità delle linee seriali,
1732 \func{cfsetispeed} per la velocità della linea di ingresso e
1733 \func{cfsetospeed} per la velocità della linea di uscita; i loro prototipi
1737 \headdecl{termios.h}
1738 \funcdecl{int cfsetispeed(struct termios *termios\_p, speed\_t speed)}
1739 Imposta la velocità delle linee seriali in ingresso.
1741 \funcdecl{int cfsetospeed(struct termios *termios\_p, speed\_t speed)}
1742 Imposta la velocità delle linee seriali in uscita.
1744 \bodydesc{Entrambe le funzioni restituiscono 0 in caso di successo e -1 in
1745 caso di errore, che avviene solo quando il valore specificato non è
1749 Si noti che le funzioni si limitano a scrivere opportunamente il valore della
1750 velocità prescelta \var{speed} all'interno della struttura puntata da
1751 \var{termios\_p}; per effettuare l'impostazione effettiva occorrerà poi
1752 chiamare \func{tcsetattr}.
1754 Si tenga presente che per le linee seriali solo alcuni valori di velocità sono
1755 validi; questi possono essere specificati direttamente (le \acr{glibc}
1756 prevedono che i valori siano indicati in bit per secondo), ma in generale
1757 altre versioni di librerie possono utilizzare dei valori diversi; per questo
1758 POSIX.1 prevede una serie di costanti che però servono solo per specificare le
1759 velocità tipiche delle linee seriali:
1761 B0 B50 B75 B110 B134 B150
1762 B200 B300 B600 B1200 B1800 B2400
1763 B4800 B9600 B19200 B38400 B57600 B115200
1767 Un terminale può utilizzare solo alcune delle velocità possibili, le funzioni
1768 però non controllano se il valore specificato è valido, dato che non possono
1769 sapere a quale terminale le velocità saranno applicate; sarà l'esecuzione di
1770 \func{tcsetattr} a fallire quando si cercherà di eseguire l'impostazione.
1772 Di norma il valore ha senso solo per i terminali seriali dove indica appunto
1773 la velocità della linea di trasmissione; se questa non corrisponde a quella
1774 del terminale quest'ultimo non potrà funzionare: quando il terminale non è
1775 seriale il valore non influisce sulla velocità di trasmissione dei dati.
1777 In generale impostare un valore nullo (\macro{B0}) sulla linea di output fa si
1778 che il modem non asserisca più le linee di controllo, interrompendo di fatto
1779 la connessione, qualora invece si utilizzi questo valore per la linea di input
1780 l'effetto sarà quello di rendere la sua velocità identica a quella della linea
1783 Analogamente a quanto avviene per l'impostazione, le velocità possono essere
1784 lette da una struttura \var{termios} utilizzando altre due funzioni,
1785 \func{cfgetispeed} e \func{cfgetospeed}, i cui prototipi sono:
1788 \headdecl{termios.h}
1789 \funcdecl{speed\_t cfgetispeed(struct termios *termios\_p)}
1790 Legge la velocità delle linee seriali in ingresso.
1792 \funcdecl{speed\_t cfgetospeed(struct termios *termios\_p)}
1793 Legge la velocità delle linee seriali in uscita.
1795 \bodydesc{Entrambe le funzioni restituiscono la velocità della linea, non
1796 sono previste condizioni di errore.}
1799 Anche in questo caso le due funzioni estraggono i valori della velocità della
1800 linea da una struttura, il cui indirizzo è specificato dall'argomento
1801 \param{termios\_p} che deve essere stata letta in precedenza con
1806 \subsection{La gestione della disciplina di linea.}
1807 \label{sec:term_line_discipline}
1809 Come illustrato dalla struttura riportata in \figref{fig:term_struct} tutti i
1810 terminali hanno un insieme di funzionalità comuni, che prevedono la presenza
1811 di code di ingresso ed uscita; in generale si fa riferimento ad esse con il
1812 nome di \textsl{discipline di linea}.
1815 Lo standard POSIX prevede alcune funzioni che permettono di intervenire
1816 direttamente sulla gestione di quest'ultime e sull'interazione fra i dati in
1817 ingresso ed uscita e le relative code. In generale tutte queste funzioni
1818 vengono considerate, dal punto di vista dell'accesso al terminale, come delle
1819 funzioni di scrittura, pertanto se usate da processi in background sul loro
1820 terminale di controllo provocano l'emissione di \macro{SIGTTOU} come
1821 illustrato in \secref{sec:sess_ctrl_term}.\footnote{con la stessa eccezione,
1822 già vista per \func{tcsetaddr}, che quest'ultimo sia bloccato o ignorato dal
1823 processo chiamante.}
1825 Una prima funzione, che è efficace solo in caso di terminali seriali asincroni
1826 (non fa niente per tutti gli altri terminali), è \func{tcsendbreak}; il suo
1830 \headdecl{termios.h}
1832 \funcdecl{int tcsendbreak(int fd, int duration)} Genera una condizione di
1833 break inviando un flusso di bit nulli.
1835 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1836 errore, nel qual caso \var{errno} assumerà i valori \macro{EBADF} o
1840 La funzione invia un flusso di bit nulli (che genera una condizione di break)
1841 sul terminale associato a \param{fd}; un valore nullo di \param{duration}
1842 implica una durata del flusso fra 0.25 e 0.5 secondi, un valore diverso da
1843 zero implica una durata pari a \code{duration*T} dove \code{T} è un valore
1844 compreso fra 0.25 e 0.5.\footnote{POSIX specifica il comportamento solo nel
1845 caso si sia impostato un valore nullo per \param{duration}; il comportamento
1846 negli altri casi può dipendere dalla implementazione.}
1848 Le altre funzioni previste da POSIX servono a controllare il comportamento
1849 dell'interazione fra le code associate al terminale e l'utente; la prima è
1850 \func{tcdrain}, il cui prototipo è:
1853 \headdecl{termios.h}
1855 \funcdecl{int tcdrain(int fd)} Attende lo svuotamento della coda di output.
1857 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1858 errore, nel qual caso \var{errno} assumerà i valori \macro{EBADF} o
1862 La funzione blocca il processo fino a che tutto l'output presente sulla coda
1863 di uscita non è stato trasmesso al terminale associato ad \param{fd}. % La
1864 % funzione è un punto di cancellazione per i
1865 % programmi multi-thread, in tal caso le
1866 % chiamate devono essere protette con dei
1867 % gestori di cancellazione.
1869 Una seconda funzione, \func{tcflush}, permette svuotare immediatamente le code
1870 di cancellando tutti i dati presenti al loro interno; il suo prototipo è:
1872 \headdecl{unistd.h} \headdecl{termios.h}
1874 \funcdecl{int tcflush(int fd, int queue)} Cancella i dati presenti
1875 nelle code di ingresso o di uscita.
1877 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1878 errore, nel qual caso \var{errno} assumerà i valori \macro{EBADF} o
1882 La funzione agisce sul terminale associato a \param{fd}, l'argomento
1883 \param{queue} permette di specificare su quale coda (ingresso, uscita o
1884 entrambe), operare. Esso può prendere i valori riportati in
1885 \tabref{tab:sess_tcflush_queue}, nel caso si specifichi la coda di ingresso
1886 cancellerà i dati ricevuti ma non ancora letti, nel caso si specifichi la coda
1887 di uscita cancellerài dati scritti ma non ancora trasmessi.
1892 \begin{tabular}[c]{|l|p{8cm}|}
1894 \textbf{Valore}& \textbf{Significato}\\
1897 \macro{TCIFLUSH} & Cancella i dati sulla coda di ingresso. \\
1898 \macro{TCOFLUSH} & Cancella i dati sulla coda di uscita. \\
1899 \macro{TCIOFLUSH}& Cancella i dati su entrambe le code.\\
1902 \caption{Possibili valori per l'argomento \param{queue} della
1903 funzione \func{tcflush}.}
1904 \label{tab:sess_tcflush_queue}
1908 L'ultima funzione dell'interfaccia che interviene sulla disciplina di linea è
1909 \func{tcflow}, che viene usata per sospendere la trasmissione e la ricezione
1910 dei dati sul terminale; il suo prototipo è:
1913 \headdecl{termios.h}
1915 \funcdecl{int tcflow(int fd, int action)}
1917 Sospende e rivvia il flusso dei dati sul terminale.
1919 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1920 errore, nel qual caso \var{errno} assumerà i valori \macro{EBADF} o
1924 La funzione permette di controllare (interrompendo e facendo riprendere) il
1925 flusso dei dati fra il terminale ed il sistema sia in ingresso che in uscita.
1926 Il comportamento della funzione è regolato dall'argomento \param{action}, i
1927 cui possibili valori, e relativa azione eseguita dalla funzione, sono
1928 riportati in \secref{tab:sess_tcflow_action}.
1933 \begin{tabular}[c]{|l|p{8cm}|}
1935 \textbf{Valore}& \textbf{Azione}\\
1938 \macro{TCOOFF}& Sospende l'output.\\
1939 \macro{TCOON} & Riprende un output precedentemente sospeso.\\
1940 \macro{TCIOFF}& Il sistema trasmette un carattere di STOP, che
1941 fa interrompere la trasmissione dei dati dal terminale. \\
1942 \macro{TCION} & Il sistema trasmette un carattere di START, che
1943 fa riprendere la trasmissione dei dati dal terminale.\\
1946 \caption{Possibili valori per l'argomento \param{action} della
1947 funzione \func{tcflow}.}
1948 \label{tab:sess_tcflow_action}
1952 \subsection{Operare in \textsl{modo non canonico}}
1953 \label{sec:term_non_canonical}
1955 Operare con un terminale in modo canonico è relativamente semplice; basta
1956 eseguire una lettura e la funzione ritornerà quando una il driver del
1957 terminale avrà completato una linea di input. Non è detto che la linea sia
1958 letta interamente (si può aver richiesto un numero inferiore di byte) ma in
1959 ogni caso nessun dato verrà perso, e il resto della linea sarà letto alla
1960 chiamata successiva.
1962 Inoltre in modo canonico la gestione dell'input è di norma eseguita
1963 direttamente dal driver del terminale, che si incarica (a seconda di quanto
1964 impostato con le funzioni viste nei paragrafi precedenti) di cancellare i
1965 caratteri, bloccare e riavviare il flusso dei dati, terminare la linea quando
1966 viene ricevuti uno dei vari caratteri di terminazione (NL, EOL, EOL2, EOF).
1968 In modo non canonico tocca invece al programma gestire tutto quanto, i
1969 caratteri NL, EOL, EOL2, EOF, ERASE, KILL, CR, REPRINT non vengono
1970 interpretati automaticamente ed inoltre, non dividendo più l'input in linee,
1971 il sistema non ha più un limite definito per quando ritornare i dati ad un
1972 processo. Per questo motivo abbiamo visto che in \var{c\_cc} sono previsti due
1973 caratteri speciali, MIN e TIME (specificati dagli indici \macro{VMIN} e
1974 \macro{VTIME} in \var{c\_cc}) che dicono al sistema di ritornare da una
1975 \func{read} quando è stata letta una determinata quantità di dati o è passato
1978 Come accennato nella relativa spiegazione in \tabref{tab:sess_termios_cc},
1979 TIME e MIN non sono in realtà caratteri ma valori numerici. Il comportamento
1980 del sistema per un terminale in modalità non canonica prevede quattro casi
1983 \item[MIN$>0$, TIME$>0$] In questo caso MIN stabilisce il numero minimo di
1984 caratteri desiderati e TIME un tempo di attesa, in decimi di secondo, fra un
1985 carattere e l'altro. Una \func{read} ritorna se vengono ricevuti almeno MIN
1986 caratteri prima della scadenza di TIME (MIN è solo un limite inferiore, se
1987 la funzione ha richiesto un numero maggiore di caratteri ne possono essere
1988 restituiti di più); se invece TIME scade vengono restituiti i byte ricevuti
1989 fino ad allora (un carattere viene sempre letto, dato che il timer inizia a
1990 scorrere solo dopo la ricezione del primo carattere).
1991 \item[MIN$>0$, TIME$=0$] Una \func{read} ritorna solo dopo che sono stati
1992 ricevuti almeno MIN caratteri. Questo significa che una \func{read} può
1993 bloccarsi indefinitamente.
1994 \item[MIN$=0$, TIME$>0$] In questo caso TIME indica un tempo di attesa dalla
1995 chiamata di \func{read}, la funzione ritorna non appena viene ricevuto un
1996 carattere o scade il tempo. Si noti che è possibile che \func{read} ritorni
1997 con un valore nullo.
1998 \item[MIN$=0$, TIME$=0$] In questo caso una \func{read} ritorna immediatamente
1999 restituendo tutti i caratteri ricevuti. Anche in questo caso può ritornare
2000 con un valore nullo.
2005 %%% Local Variables:
2007 %%% TeX-master: "gapil"