per far questo vengono utilizzati due ulteriori identificatori (oltre quelli
visti in \secref{sec:proc_pid}) che il kernel associa a ciascun
processo:\footnote{in Linux questi identificatori sono mantenuti nei campi
- \var{pgrp} e \var{session} della struttura \var{task\_struct} definita in
+ \var{pgrp} e \var{session} della struttura \struct{task\_struct} definita in
\file{sched.h}.} l'identificatore del \textit{process group} e
l'identificatore della \textsl{sessione}, che vengono indicati rispettivamente
con le sigle \acr{pgid} e \acr{sid}, e sono mantenuti in variabili di tipo
dei suoi figli, ed in quest'ultimo caso ha successo soltanto se questo non ha
ancora eseguito una \func{exec}.\footnote{questa caratteristica è implementata
dal kernel che mantiene allo scopo un altro campo, \var{did\_exec}, in
- \var{task\_struct}.} Specificando un valore nullo per \param{pid} si indica
-il processo corrente, mentre specificando un valore nullo per \param{pgid} si
-imposta il \textit{process group} al valore del \acr{pid} del processo
-selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0, 0)}.
+ \struct{task\_struct}.} Specificando un valore nullo per \param{pid} si
+indica il processo corrente, mentre specificando un valore nullo per
+\param{pgid} si imposta il \textit{process group} al valore del \acr{pid} del
+processo selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0,
+ 0)}.
Di norma questa funzione viene usata dalla shell quando si usano delle
pipeline, per mettere nello stesso process group tutti i programmi lanciati su
\textit{process group} di cui esso diventa leader (come per i \textit{process
group} un processo si dice leader di sessione\footnote{in Linux la proprietà
è mantenuta in maniera indipendente con un apposito campo \var{leader} in
- \var{task\_struct}.} se il suo \acr{sid} è uguale al suo \acr{pid}) ed unico
-componente. Inoltre la funzione distacca il processo da ogni terminale di
-controllo (torneremo sull'argomento in \secref{sec:sess_ctrl_term}) cui fosse
-in precedenza associato.
+ \struct{task\_struct}.} se il suo \acr{sid} è uguale al suo \acr{pid}) ed
+unico componente. Inoltre la funzione distacca il processo da ogni terminale
+di controllo (torneremo sull'argomento in \secref{sec:sess_ctrl_term}) cui
+fosse in precedenza associato.
La funzione ha successo soltanto se il processo non è già leader di un
\textit{process group}, per cui per usarla di norma si esegue una \func{fork}
mantenendo fra gli attributi di ciascun processo anche qual'è il suo terminale
di controllo. \footnote{Lo standard POSIX.1 non specifica nulla riguardo
l'implementazione; in Linux anch'esso viene mantenuto nella solita struttura
- \var{task\_struct}, nel campo \var{tty}.} In generale ogni processo eredita
-dal padre, insieme al \acr{pgid} e al \acr{sid} anche il terminale di
+ \struct{task\_struct}, nel campo \var{tty}.} In generale ogni processo
+eredita dal padre, insieme al \acr{pgid} e al \acr{sid} anche il terminale di
controllo (vedi \secref{sec:proc_fork}). In questo modo tutti processi
originati dallo stesso leader di sessione mantengono lo stesso terminale di
controllo.
Il servizio prevede vari meccanismi di notifica, e, come ogni altro servizio
in un sistema unix-like, viene gestito attraverso un apposito programma,
\cmd{syslogd}, che è anch'esso un \textsl{demone}. In generale i messaggi di
-errore vengono raccolti dal file speciale \file{/dev/log}, un \textit{socket}
-locale (vedi \secref{sec:sock_sa_local}) dedicato a questo scopo, o via rete,
-con un \textit{socket} UDP, o da un apposito demone, \cmd{klogd}, che estrae i
-messaggi del kernel.\footnote{i messaggi del kernel sono tenuti in un buffer
- circolare e scritti tramite la funzione \func{printk}, analoga alla
- \func{printf} usata in user space; una trattazione eccellente dell'argomento
- si trova in \cite{LinDevDri}, nel quarto capitolo.}
+errore vengono raccolti dal file speciale \file{/dev/log}, un
+\textit{socket}\index{socket} locale (vedi \secref{sec:sock_sa_local})
+dedicato a questo scopo, o via rete, con un \textit{socket} UDP, o da un
+apposito demone, \cmd{klogd}, che estrae i messaggi del kernel.\footnote{i
+ messaggi del kernel sono tenuti in un buffer circolare e scritti tramite la
+ funzione \func{printk}, analoga alla \func{printf} usata in user space; una
+ trattazione eccellente dell'argomento si trova in \cite{LinDevDri}, nel
+ quarto capitolo.}
Il servizio permette poi di trattare i vari messaggi classificandoli
attraverso due indici; il primo, chiamato \textit{facility}, suddivide in
Le \acr{glibc} definiscono una serie di funzioni standard con cui un processo
può accedere in maniera generica al servizio di \textit{syslog}, che però
funzionano solo localmente; se si vogliono inviare i messaggi ad un'altro
-sistema occorre farlo esplicitamente con un socket UDP, o utilizzare le
-capacità di reinvio del servizio.
+sistema occorre farlo esplicitamente con un socket\index{socket} UDP, o
+utilizzare le capacità di reinvio del servizio.
La prima funzione definita dall'interfaccia è \func{openlog}, che apre una
connessione al servizio di \textit{syslog}; essa in generale non è necessaria
inoltre non è detto che il processo possa effettivamente aprire il terminale.
I vari attributi vengono mantenuti per ciascun terminale in una struttura
-\var{termios}, (la cui definizione è riportata in \figref{fig:term_termios}),
-usata dalle varie funzioni dell'interfaccia. In \figref{fig:term_termios} si
-sono riportati tutti i campi della definizione usata in Linux; di questi solo
-i primi cinque sono previsti dallo standard POSIX.1, ma le varie
-implementazioni ne aggiungono degli altri per mantenere ulteriori
-informazioni.\footnote{la definizione della struttura si trova in
+\struct{termios}, (la cui definizione è riportata in
+\figref{fig:term_termios}), usata dalle varie funzioni dell'interfaccia. In
+\figref{fig:term_termios} si sono riportati tutti i campi della definizione
+usata in Linux; di questi solo i primi cinque sono previsti dallo standard
+POSIX.1, ma le varie implementazioni ne aggiungono degli altri per mantenere
+ulteriori informazioni.\footnote{la definizione della struttura si trova in
\file{bits/termios.h}, da non includere mai direttamente, Linux, seguendo
l'esempio di BSD, aggiunge i due campi \var{c\_ispeed} e \var{c\_ospeed} per
mantenere le velocità delle linee seriali, ed un campo ulteriore,
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \var{termios}, che identifica le proprietà di un
+ \caption{La struttura \structd{termios}, che identifica le proprietà di un
terminale.}
\label{fig:term_termios}
\end{figure}
\const{CBAUD} & Maschera dei bit (4+1) usati per impostare della velocità
della linea (il \textit{baud rate}) in ingresso.
In Linux non è implementato in quanto viene
- usato un apposito campo di \var{termios}.\\
+ usato un apposito campo di \struct{termios}.\\
\const{CBAUDEX}& Bit aggiuntivo per l'impostazione della velocità della
linea, per le stesse motivazioni del precedente non è
implementato in Linux.\\
\const{CIBAUD} & Maschera dei bit della velocità della linea in
ingresso. Analogo a \const{CBAUD}, anch'esso in Linux è
- mantenuto in un apposito campo di \var{termios}. \\
+ mantenuto in un apposito campo di \struct{termios}. \\
\const{CRTSCTS}& Abilita il controllo di flusso hardware sulla seriale,
attraverso l'utilizzo delle dei due fili di RTS e CTS.\\
\hline
funzioni di lettura e scrittura) che mantengono le velocità delle linee
seriali all'interno dei flag; come accennato in Linux questo viene fatto
(seguendo l'esempio di BSD) attraverso due campi aggiuntivi, \var{c\_ispeed} e
-\var{c\_ospeed}, nella struttura \var{termios} (mostrati in
+\var{c\_ospeed}, nella struttura \struct{termios} (mostrati in
\figref{fig:term_termios}).
\begin{table}[b!ht]
non è impostato \const{ICANON}.
Oltre ai vari flag per gestire le varie caratteristiche dei terminali,
-\var{termios} contiene pure il campo \var{c\_cc} che viene usato per impostare
-i caratteri speciali associati alle varie funzioni di controllo. Il numero di
-questi caratteri speciali è indicato dalla costante \const{NCCS}, POSIX ne
-specifica almeno 11, ma molte implementazioni ne definiscono molti
+\struct{termios} contiene pure il campo \var{c\_cc} che viene usato per
+impostare i caratteri speciali associati alle varie funzioni di controllo. Il
+numero di questi caratteri speciali è indicato dalla costante \const{NCCS},
+POSIX ne specifica almeno 11, ma molte implementazioni ne definiscono molti
altri.\footnote{in Linux il valore della costante è 32, anche se i caratteri
effettivamente definiti sono solo 17.}
\hline
\end{tabular}
\caption{Valori dei caratteri di controllo mantenuti nel campo \var{c\_cc}
- della struttura \var{termios}.}
+ della struttura \struct{termios}.}
\label{tab:sess_termios_cc}
\end{table}
Per leggere ed scrivere tutte le impostazioni dei terminali lo standard POSIX
prevede due funzioni, \func{tcgetattr} e \func{tcsetattr}; entrambe utilizzano
-come argomento un puntatore ad struttura \var{termios} che sarà quella in cui
-andranno immagazzinate le impostazioni, il loro prototipo è:
+come argomento un puntatore ad struttura \struct{termios} che sarà quella in
+cui andranno immagazzinate le impostazioni, il loro prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{termios.h}
Al contrario di tutte le altre caratteristiche dei terminali, che possono
essere impostate esplicitamente utilizzando gli opportuni campi di
-\var{termios}, per le velocità della linea (il cosiddetto \textit{baud rate})
-non è prevista una implementazione standardizzata, per cui anche se in Linux
-sono mantenute in due campi dedicati nella struttura, questi non devono essere
-acceduti direttamente ma solo attraverso le apposite funzioni di interfaccia
-provviste da POSIX.1.
+\struct{termios}, per le velocità della linea (il cosiddetto \textit{baud
+ rate}) non è prevista una implementazione standardizzata, per cui anche se
+in Linux sono mantenute in due campi dedicati nella struttura, questi non
+devono essere acceduti direttamente ma solo attraverso le apposite funzioni di
+interfaccia provviste da POSIX.1.
Lo standard prevede due funzioni per scrivere la velocità delle linee seriali,
\func{cfsetispeed} per la velocità della linea di ingresso e
\end{functions}
Si noti che le funzioni si limitano a scrivere opportunamente il valore della
-velocità prescelta \var{speed} all'interno della struttura puntata da
-\var{termios\_p}; per effettuare l'impostazione effettiva occorrerà poi
-chiamare \func{tcsetattr}.
+velocità prescelta \param{speed} all'interno della struttura puntata da
+\param{termios\_p}; per effettuare l'impostazione effettiva occorrerà poi
+chiamare \func{tcsetattr}.
Si tenga presente che per le linee seriali solo alcuni valori di velocità sono
validi; questi possono essere specificati direttamente (le \acr{glibc}
di output.
Analogamente a quanto avviene per l'impostazione, le velocità possono essere
-lette da una struttura \var{termios} utilizzando altre due funzioni,
-\func{cfgetispeed} e \func{cfgetospeed}, i cui prototipi sono:
+lette da una struttura \struct{termios} utilizzando altre due funzioni,
+\funcd{cfgetispeed} e \funcd{cfgetospeed}, i cui prototipi sono:
\begin{functions}
\headdecl{unistd.h}
\headdecl{termios.h}