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
Un \textit{process group} è pertanto definito da tutti i processi che hanno lo
stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con
-le funzioni \func{getpgid} e \func{getpgrp},\footnote{\func{getpgrp} è
+le funzioni \funcd{getpgid} e \funcd{getpgrp},\footnote{\func{getpgrp} è
definita nello standard POSIX.1, mentre \func{getpgid} è richiesta da SVr4.}
i cui prototipi sono:
\begin{functions}
equivalente a \code{getpgid(0)}.
In maniera analoga l'identificatore della sessione può essere letto dalla
-funzione \func{getsid}, che però nelle \acr{glibc}\footnote{la system call è
+funzione \funcd{getsid}, che però nelle \acr{glibc}\footnote{la system call è
stata introdotta in Linux a partire dalla versione 1.3.44, il supporto nelle
librerie del C è iniziato dalla versione 5.2.19. La funzione non è prevista
da POSIX.1, che parla solo di processi leader di sessione, e non di
cosiddetto \textit{process group leader}, che è identificato dall'avere un
\acr{pgid} uguale al suo \acr{pid}, in genere questo è il primo processo del
raggruppamento, che si incarica di lanciare tutti gli altri. Un nuovo
-raggruppamento si crea con la funzione \func{setpgrp},\footnote{questa è la
+raggruppamento si crea con la funzione \funcd{setpgrp},\footnote{questa è la
definizione di POSIX.1, BSD definisce una funzione con lo stesso nome, che
però è identica a \func{setpgid}; nelle \acr{glibc} viene sempre usata
sempre questa definizione, a meno di non richiedere esplicitamente la
corrente, rende questo \textit{group leader} di un nuovo raggruppamento, tutti
i successivi processi da esso creati apparterranno (a meno di non cambiare di
nuovo il \acr{pgid}) al nuovo raggruppamento. È possibile invece spostare un
-processo da un raggruppamento ad un altro con la funzione \func{setpgid}, il
+processo da un raggruppamento ad un altro con la funzione \funcd{setpgid}, il
cui prototipo è:
\begin{prototype}{unistd.h}{int setpgid(pid\_t pid, pid\_t pgid)}
Assegna al \acr{pgid} del processo \param{pid} il valore \param{pgid}.
\begin{errlist}
\item[\errcode{ESRCH}] Il processo selezionato non esiste.
\item[\errcode{EPERM}] Il cambiamento non è consentito.
- \item[\errcode{EACCESS}] Il processo ha già eseguito una \func{exec}.
+ \item[\errcode{EACCES}] Il processo ha già eseguito una \func{exec}.
\item[\errcode{EINVAL}] Il valore di \param{pgid} è negativo.
\end{errlist}
}
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
sé stesso, in modo che il cambiamento di \textit{process group} sia immediato
per entrambi; una delle due chiamate sarà ridondante, ma non potendo
determinare quale dei due processi viene eseguito per primo, occorre eseguirle
-comunque entrambe per evitare di esporsi ad una race condition.
+comunque entrambe per evitare di esporsi ad una race
+condition\index{race condition}.
Si noti come nessuna delle funzioni esaminate finora permetta di spostare un
processo da una sessione ad un altra; infatti l'unico modo di far cambiare
sessione ad un processo è quello di crearne una nuova con l'uso di
-\func{setsid}; il suo prototipo è:
+\funcd{setsid}; il suo prototipo è:
\begin{prototype}{unistd.h}{pid\_t setsid(void)}
Crea una nuova sessione sul processo corrente impostandone \acr{sid} e
\acr{pgid}.
\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.
sessione, ma solo quelli che fanno parte del cosiddetto raggruppamento di
\textit{foreground}, possono leggere e scrivere in certo istante. Per
impostare il raggruppamento di \textit{foreground} di un terminale si usa la
-funzione \func{tcsetpgrp}, il cui prototipo è:
+funzione \funcd{tcsetpgrp}, il cui prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{termios.h}
funzioni di lettura e scrittura falliranno con un errore di \errcode{EIO}.
Un processo può controllare qual'è il gruppo di \textit{foreground} associato
-ad un terminale con la funzione \func{tcgetpgrp}, il cui prototipo è:
+ad un terminale con la funzione \funcd{tcgetpgrp}, il cui prototipo è:
\begin{functions}
\headdecl{unistd.h} \headdecl{termios.h}
Infine attraverso l'uso di \func{setuid}, \func{setpid} e \func{initgroups}
verrà cambiata l'identità del proprietario del processo, infatti, come
spiegato in \secref{sec:proc_setuid}, avendo invocato tali funzioni con i
-privilegi di amministratore, tutti gli userid ed i groupid (reali, effettivi e
-salvati) saranno settati a quelli dell'utente.
+privilegi di amministratore, tutti gli user-ID ed i group-ID (reali, effettivi
+e salvati) saranno settati a quelli dell'utente.
A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
In Linux buona parte di queste azioni possono venire eseguite invocando la
-funzione \func{daemon}, introdotta per la prima volta in BSD4.4; il suo
+funzione \funcd{daemon}, introdotta per la prima volta in BSD4.4; il suo
prototipo è:
\begin{prototype}{unistd.h}{int daemon(int nochdir, int noclose)}
Esegue le operazioni che distaccano il processo dal terminale di controllo e
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
+La prima funzione definita dall'interfaccia è \funcd{openlog}, che apre una
connessione al servizio di \textit{syslog}; essa in generale non è necessaria
per l'uso del servizio, ma permette di impostare alcuni valori che controllano
gli effetti delle chiamate successive; il suo prototipo è:
\label{tab:sess_openlog_option}
\end{table}
-La funzione che si usa per generare un messaggio è \func{syslog}, dato che
+La funzione che si usa per generare un messaggio è \funcd{syslog}, dato che
l'uso di \func{openlog} è opzionale, sarà quest'ultima a provvede a chiamare la
prima qualora ciò non sia stato fatto (nel qual caso il valore di
\param{ident} è nullo). Il suo prototipo è:
\label{tab:sess_syslog_priority}
\end{table}
-Una ulteriore funzione, \func{setlogmask}, permette di filtrare
+Una ulteriore funzione, \funcd{setlogmask}, permette di filtrare
preliminarmente i messaggi in base alla loro priorità; il suo prototipo è:
\begin{prototype}{syslog.h}{int setlogmask(int mask)}
origine molte operazioni venivano effettuate con \func{ioctl}), ma ovviamente
possono essere usate solo con file che corrispondano effettivamente ad un
terminale (altrimenti si otterrà un errore di \errcode{ENOTTY}); questo può
-essere evitato utilizzando la funzione \func{isatty}, il cui prototipo è:
+essere evitato utilizzando la funzione \funcd{isatty}, il cui prototipo è:
\begin{prototype}{unistd.h}{int isatty(int desc)}
Controlla se il file descriptor \param{desc} è un terminale.
terminale, 0 altrimenti.}
\end{prototype}
-Un'altra funzione che fornisce informazioni su un terminale è \func{ttyname},
+Un'altra funzione che fornisce informazioni su un terminale è \funcd{ttyname},
che permette di ottenere il nome del terminale associato ad un file
descriptor; il suo prototipo è:
\begin{prototype}{unistd.h}{char *ttyname(int desc)}
Si tenga presente che la funzione restituisce un indirizzo di dati statici,
che pertanto possono essere sovrascritti da successive chiamate. Una funzione
-funzione analoga, anch'essa prevista da POSIX.1, è \func{ctermid}, il cui
+funzione analoga, anch'essa prevista da POSIX.1, è \funcd{ctermid}, il cui
prototipo è:
\begin{prototype}{stdio.h}{char *ctermid(char *s)}
indica la dimensione che deve avere una stringa per poter contenere il nome
di un terminale.} caratteri.
-Esiste infine una versione rientrante \func{ttyname\_r} della funzione
+Esiste infine una versione rientrante \funcd{ttyname\_r} della funzione
\func{ttyname}, che non presenta il problema dell'uso di una zona di memoria
statica; il suo prototipo è:
\begin{prototype}{unistd.h}{int ttyname\_r(int desc, char *buff, size\_t len)}
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{CSIZE} & Maschera per i bit usati per specificare la dimensione
del carattere inviato lungo la linea di trasmissione, i
valore ne indica la lunghezza (in bit), ed i valori
- possibili sono \const{CS5}, \const{CS6},
- \const{CS7} e \const{CS8}
+ possibili sono \val{CS5}, \val{CS6},
+ \val{CS7} e \val{CS8}
corrispondenti ad un analogo numero di bit.\\
\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}
settato \const{IEXTEN}. In ogni caso quando vengono attivati i caratteri
vengono interpretati e non sono passati sulla coda di ingresso.
-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 è:
+Per leggere ed scrivere tutte le varie impostazioni dei terminali viste finora
+lo standard POSIX prevede due funzioni che utilizzano come argomento un
+puntatore ad una struttura \struct{termios} che sarà quella in cui andranno
+immagazzinate le impostazioni. Le funzioni sono \funcd{tcgetattr} e
+\funcd{tcsetattr} ed 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
-\func{cfsetospeed} per la velocità della linea di uscita; i loro prototipi
+\funcd{cfsetispeed} per la velocità della linea di ingresso e
+\funcd{cfsetospeed} per la velocità della linea di uscita; i loro prototipi
sono:
\begin{functions}
\headdecl{unistd.h}
\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}
POSIX.1 prevede una serie di costanti che però servono solo per specificare le
velocità tipiche delle linee seriali:
\begin{verbatim}
- B0 B50 B75 B110 B134 B150
- B200 B300 B600 B1200 B1800 B2400
- B4800 B9600 B19200 B38400 B57600 B115200
+ B0 B50 B75
+ B110 B134 B150
+ B200 B300 B600
+ B1200 B1800 B2400
+ B4800 B9600 B19200
+ B38400 B57600 B115200
B230400 B460800
\end{verbatim}
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}
processo chiamante.}
Una prima funzione, che è efficace solo in caso di terminali seriali asincroni
-(non fa niente per tutti gli altri terminali), è \func{tcsendbreak}; il suo
+(non fa niente per tutti gli altri terminali), è \funcd{tcsendbreak}; il suo
prototipo è:
\begin{functions}
\headdecl{unistd.h}
Le altre funzioni previste da POSIX servono a controllare il comportamento
dell'interazione fra le code associate al terminale e l'utente; la prima è
-\func{tcdrain}, il cui prototipo è:
+\funcd{tcdrain}, il cui prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{termios.h}
% chiamate devono essere protette con dei
% gestori di cancellazione.
-Una seconda funzione, \func{tcflush}, permette svuotare immediatamente le code
+Una seconda funzione, \funcd{tcflush}, permette svuotare immediatamente le code
di cancellando tutti i dati presenti al loro interno; il suo prototipo è:
\begin{functions}
\headdecl{unistd.h} \headdecl{termios.h}
entrambe), operare. Esso può prendere i valori riportati in
\tabref{tab:sess_tcflush_queue}, nel caso si specifichi la coda di ingresso
cancellerà i dati ricevuti ma non ancora letti, nel caso si specifichi la coda
-di uscita cancellerài dati scritti ma non ancora trasmessi.
+di uscita cancellerà i dati scritti ma non ancora trasmessi.
\begin{table}[htb]
\footnotesize
L'ultima funzione dell'interfaccia che interviene sulla disciplina di linea è
-\func{tcflow}, che viene usata per sospendere la trasmissione e la ricezione
+\funcd{tcflow}, che viene usata per sospendere la trasmissione e la ricezione
dei dati sul terminale; il suo prototipo è:
\begin{functions}
\headdecl{unistd.h}
\funcdecl{int tcflow(int fd, int action)}
- Sospende e rivvia il flusso dei dati sul terminale.
+ Sospende e riavvia il flusso dei dati sul terminale.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o
projects / gapil.git / blobdiff