From: Simone Piccardi Date: Sat, 16 Feb 2002 19:32:51 +0000 (+0000) Subject: Correzioni parte seconda. Tolto un pezzo duplicato X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=470f15a82390d6120981e85202f45fc102f3e8a3;p=gapil.git Correzioni parte seconda. Tolto un pezzo duplicato --- diff --git a/fileintro.tex b/fileintro.tex index 927dc4d..010add3 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -22,7 +22,7 @@ delle modalit -\section{L'architettura dell'accesso} +\section{L'architettura generale} \label{sec:file_access_arch} Per poter accedere ai file il kernel deve mettere a disposizione dei programmi @@ -30,8 +30,9 @@ le opportune interfacce che consentano di leggerne il contenuto; il sistema cioè deve provvedere ad organizzare e rendere accessibile in maniera opportuna l'informazione tenuta sullo spazio grezzo disponibile sui dischi. Questo viene fatto strutturando l'informazione sul disco attraverso quello che si chiama un -\textit{filesystem}, essa poi viene resa disponibile ai processi attraverso -quello che viene chiamato il \textsl{montaggio} del filesystem. +\textit{filesystem} (vedi \ref{sec:file_arch_func}), essa poi viene resa +disponibile ai processi attraverso quello che viene chiamato il +\textsl{montaggio} del \textit{filesystem}. % (approfondiremo tutto ciò in \secref{sec:file_arch_func}). In questa sezione faremo una panormamica generica su come il sistema presenta @@ -52,15 +53,15 @@ viene identificato dall'utente usando quello che viene chiamato ricerca (come quello in cui si cercano i comandi) non seguiremo questa scelta dato che l'uso della parola \textit{pathname} è ormai così comune che mantenerne l'uso è senz'altro più chiaro dell'alternativa proposta.}, cioè -il percorso che si deve fare per accedere al file, che è composto da una serie -di nomi separati da una \file{/}. +il percorso che si deve fare per accedere al file a partire dalla \textit{root + directory}, che è composto da una serie di nomi separati da una \file{/}. -Dopo la fase di inizializzazione il kernel riceve dal boot loader -l'indicazione di quale dispositivo contiene il filesystem da usare come punto -di partenza e questo viene montato come radice dell'albero (cioè nella -directory \file{/}); tutti gli ulteriori filesystem che possono essere su -altri dispositivi devono poi essere inseriti nell'albero montandoli su -opportune directory del filesystem montato come radice. +All'avvio del sistema, comletata la fase di inizializzazione il kernel riceve +dal boot loader l'indicazione di quale dispositivo contiene il filesystem da +usare come punto di partenza e questo viene montato come radice dell'albero +(cioè nella directory \file{/}); tutti gli ulteriori filesystem che possono +essere su altri dispositivi dovranno poi essere inseriti nell'albero +montandoli su opportune directory del filesystem montato come radice. Alcuni filesystem speciali (come \file{/proc} che contiene un'interfaccia ad alcune strutture interne del kernel) sono generati automaticamente dal kernel @@ -87,7 +88,7 @@ Il nome completo di un file viene chiamato \textit{pathname} ed il procedimento con cui si individua il file a cui esso fa riferimento è chiamato risoluzione del nome (\textit{file name resolution} o \textit{pathname resolution}). La risoluzione viene fatta esaminando il \textit{pathname} da -destra a sinistra e localizzando ogni nome nella directory indicata dal nome +sinistra a destra e localizzando ogni nome nella directory indicata dal nome precedente usando \file{/} come separatore\footnote{nel caso di nome vuoto, il costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente perché il procedimento funzioni occorre che i nomi indicati come directory @@ -113,7 +114,7 @@ questa sia la directory radice allora il riferimento \subsection{I tipi di file} \label{sec:file_file_types} -Come detto in precedenza in unix esistono vari tipi di file, in Linux questi +Come detto in precedenza in Unix esistono vari tipi di file, in Linux questi sono implementati come oggetti del \textit{Virtual File System} (vedi \secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal @@ -142,10 +143,10 @@ dati) in base al loro contenuto, o tipo di accesso. un file che identifica una periferica ad accesso sequenziale \\ \textit{block device} & \textsl{dispositivo a blocchi} & un file che identifica una periferica ad accesso diretto \\ - \textit{fifo} & \textsl{tubo} & + \textit{fifo} & \textsl{``tubo''} & un file speciale che identifica una linea di comunicazione software (unidirezionale) \\ - \textit{socket} & \textsl{manicotto} & + \textit{socket} & \textsl{``spina''} & un file speciale che identifica una linea di comunicazione software (bidirezionale) \\ \hline @@ -171,18 +172,26 @@ riga problemi qualora nei programmi si facciano assunzioni sul terminatore della riga. +Si ricordi infine che in ambiente Unix non esistono tipizzazioni dei file di +dati e che non c'è nessun supporto del sistema per le estensioni come parte +del filesystem. Ciò non ostante molti programmi adottano delle convenzioni per +i nomi dei file, ad esempio il codice C normalmente si mette in file con +l'estensione \file{.c}, ma questa è, appunto, solo una convenzione. + + \subsection{Le due interfacce ai file} \label{sec:file_io_api} -In unix le modalità di accesso ai file e le relative interfacce di +In Linux le modalità di accesso ai file e le relative interfacce di programmazione sono due, basate su due diversi meccanismi con cui è possibile accedere al loro contenuto. -La prima è l'interfaccia standard di unix, quella che il manuale delle +La prima è l'interfaccia standard di Unix, quella che il manuale delle \acr{glibc} chiama interfaccia dei descrittori di file (o \textit{file - descriptor}). È un'interfaccia specifica di unix e provvede un accesso non -bufferizzato, la tratteremo in dettaglio in \capref{cha:file_unix_interface}. + descriptor}). È un'interfaccia specifica dei sistemi unix-like e provvede +un accesso non bufferizzato; la tratteremo in dettaglio in +\capref{cha:file_unix_interface}. L'interfaccia è primitiva ed essenziale, l'accesso viene detto non bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando @@ -194,8 +203,8 @@ L'interfaccia La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli \textit{stream}\index{stream}, essa provvede funzioni più evolute e un accesso -bufferizzato (controllato dalla implementazione fatta dalle librerie del C), -la tratteremo in dettaglio in \capref{cha:files_std_interface}. +bufferizzato (controllato dalla implementazione fatta dalle \acr{glibc}), la +tratteremo in dettaglio nel \capref{cha:files_std_interface}. Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova anche su tutti i sistemi non Unix. Gli \textit{stream} sono oggetti complessi @@ -205,22 +214,21 @@ tipo \type{FILE *}. L'interfaccia Entrambe le interfacce possono essere usate per l'accesso ai file come agli altri oggetti del VFS (pipe, socket, device, sui quali torneremo in dettaglio -a tempo opportuno), ma per poter accedere alle operazioni di controllo sul -particolare tipo di oggetto del VFS scelto occorre usare l'interfaccia -standard di Unix coi \textit{file descriptor}. Allo stesso modo devono essere -usati i \textit{file descriptor} se si vuole ricorrere a modalità speciali di -I/O come il polling o il non-bloccante (vedi \capref{cha:file_advanced}). +a tempo opportuno), ma per poter accedere alle operazioni di controllo su un +qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix +coi \textit{file descriptor}. Allo stesso modo devono essere usati i +\textit{file descriptor} se si vuole ricorrere a modalità speciali di I/O come +il polling o il non-bloccante (vedi \capref{cha:file_advanced}). Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra -quella dei \textit{file descriptor}, che tratta tutti i file nello stesso -modo, con l'eccezione di poter scegliere tra diversi stili di bufferizzazione. -Il maggior vantaggio degli \textit{stream} è che l'interfaccia per le -operazioni di input/output è enormemente più ricca di quella dei \textit{file - descriptor}, che provvedono solo funzioni elementari per la -lettura/scrittura diretta di blocchi di byte. In particolare gli -\textit{stream} dispongono di tutte le funzioni di formattazione per l'input e -l'output adatte per manipolare anche i dati in forma di linee o singoli -caratteri. +quella dei \textit{file descriptor}, che permette di poter scegliere tra +diversi stili di bufferizzazione. Il maggior vantaggio degli \textit{stream} +è che l'interfaccia per le operazioni di input/output è enormemente più ricca +di quella dei \textit{file descriptor}, che provvedono solo funzioni +elementari per la lettura/scrittura diretta di blocchi di byte. In +particolare gli \textit{stream} dispongono di tutte le funzioni di +formattazione per l'input e l'output adatte per manipolare anche i dati in +forma di linee o singoli caratteri. In ogni caso, dato che gli stream sono implementati sopra l'interfaccia standard di Unix, è sempre possibile estrarre il \textit{file descriptor} da @@ -229,66 +237,60 @@ tempo uno \textit{stream} ad un \textit{file descriptor}. In generale, se non necessitano specificatamente le funzionalità di basso livello, è opportuno usare sempre gli \textit{stream} per la loro maggiore -portabilità essendo questi ultimi definiti nello standard ANSI C; -l'interfaccia con i \textit{file descriptor} invece segue solo lo standard -POSIX.1 dei sistemi unix ed è pertanto di portabilità più limitata. - - -\subsection{Caratteristiche specifiche dei file in Unix} -\label{sec:fileint_unix_spec} - -Essendo un sistema multitasking e multiutente esistono alcune caratteristiche -specifiche di un sistema unix-like che devono essere tenute in conto -nell'accesso ai file. È infatti normale che più processi o programmi possano -accedere contemporaneamente allo stesso file e devono poter eseguire le loro -operazioni indipendentemente da quello che fanno gli altri processi. - -Per questo motivo le strutture usate per all'accesso ai file sono relative al -processo che effettua l'accesso. All'apertura di ogni file infatti viene -creata all'interno del processo una apposita struttura in cui sono memorizzati -tutti gli attributi del medesimo, che viene utilizzata per tutte le -operazioni. Questa è una struttura che resta locale al processo stesso; in -questo modo processi diversi possono usare le proprie strutture locali per -accedere ai file (che può essere sempre lo stesso) in maniera assolutamente -indipendente. - -Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i -sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel -file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione -successiva. Essa è rappresentata da un numero intero che indica il numero di -byte dall'inizio del file, che viene (a meno che non si apra il file in -append) inizializzato a zero all'apertura del medesimo. - -Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui -ogni processo avrà la sua posizione corrente nel file, che non sarà -influenzata da quello che altri processi possono fare. Anzi, aprire un file -significa appunto creare ed inizializzare una tale struttura, per cui se si -apre due volte lo stesso file all'interno dello stesso processo, si otterranno -due file descriptor o due stream che avranno ancora una posizione corrente nel -file assolutamente indipendente. - -Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di -accesso è un riferimento all'inode del file, pertanto anche se il file viene -cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai -dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà -chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo -in dettaglio in \secref{sec:file_link}) aprire un file provvisorio per -cancellarlo immediatamente dopo; in questo modo all'uscita del programma il -file scomparirà definitivamente dal disco, ma il file ed il suo contenuto -saranno disponibili per tutto il tempo in cui il processo è attivo. - -Ritorneremo su questo più avanti in \secref{sec:file_fd}, quando tratteremo -l'input/output sui file, esaminando in dettaglio come tutto ciò viene -realizzato. - -Si ricordi infine che in ambiente unix non esistono i tipi di file e che non -c'è nessun supporto per le estensioni come parte del filesystem. Ciò non -ostante molti programmi adottano delle convenzioni per i nomi dei file, ad -esempio il codice C normalmente si mette in file con l'estensione .c, ma -questa è, appunto, solo una convenzione. - - -\section{L'architettura di funzionamento} +portabilità, essendo questi ultimi definiti nello standard ANSI C; +l'interfaccia con i \textit{file descriptor} infatti segue solo lo standard +POSIX.1 dei sistemi Unix, ed è pertanto di portabilità più limitata. + + +% \subsection{Caratteristiche specifiche dei file in Unix} +% \label{sec:fileint_unix_spec} + +% Essendo un sistema multitasking e multiutente esistono alcune caratteristiche +% specifiche di un sistema unix-like che devono essere tenute in conto +% nell'accesso ai file. È infatti normale che più processi o programmi possano +% accedere contemporaneamente allo stesso file e devono poter eseguire le loro +% operazioni indipendentemente da quello che fanno gli altri processi. + +% Per questo motivo le strutture usate per all'accesso ai file sono relative al +% processo che effettua l'accesso. All'apertura di ogni file infatti viene +% creata all'interno del processo una apposita struttura in cui sono memorizzati +% tutti gli attributi del medesimo, che viene utilizzata per tutte le +% operazioni. Questa è una struttura che resta locale al processo stesso; in +% questo modo processi diversi possono usare le proprie strutture locali per +% accedere ai file (che può essere sempre lo stesso) in maniera assolutamente +% indipendente. + +% Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i +% sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel +% file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione +% successiva. Essa è rappresentata da un numero intero che indica il numero di +% byte dall'inizio del file, che viene (a meno che non si apra il file in +% append) inizializzato a zero all'apertura del medesimo. + +% Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui +% ogni processo avrà la sua posizione corrente nel file, che non sarà +% influenzata da quello che altri processi possono fare. Anzi, aprire un file +% significa appunto creare ed inizializzare una tale struttura, per cui se si +% apre due volte lo stesso file all'interno dello stesso processo, si otterranno +% due file descriptor o due stream che avranno ancora una posizione corrente nel +% file assolutamente indipendente. + +% Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di +% accesso è un riferimento all'inode del file, pertanto anche se il file viene +% cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai +% dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà +% chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo +% in dettaglio in \secref{sec:file_link}) aprire un file provvisorio per +% cancellarlo immediatamente dopo; in questo modo all'uscita del programma il +% file scomparirà definitivamente dal disco, ma il file ed il suo contenuto +% saranno disponibili per tutto il tempo in cui il processo è attivo. + +% Ritorneremo su questo più avanti in \secref{sec:file_fd}, quando tratteremo +% l'input/output sui file, esaminando in dettaglio come tutto ciò viene +% realizzato. + + +\section{L'architettura della gestione dei file} \label{sec:file_arch_func} Per capire fino in fondo le proprietà di file e directory in un sistema diff --git a/prochand.tex b/prochand.tex index 173c0be..4eb3d74 100644 --- a/prochand.tex +++ b/prochand.tex @@ -991,13 +991,13 @@ le apposite funzioni trattate in \secref{sec:sig_strsignal}. \subsection{Le funzioni \func{wait3} e \func{wait4}} \label{sec:proc_wait4} -Linux, seguendo una estensione di BSD, supporta altre due funzioni, -\func{wait} e \func{waitpd}, per la lettura dello stato di terminazione di un -processo, analoghe alle precedenti ma che prevedono un ulteriore parametro -attraverso il quale il kernel può restituire al padre informazioni sulle -risorse usate dal processo terminato e dai vari figli. I prototipi di queste -funzioni, che diventano accessibili definendo la costante \macro{\_USE\_BSD}, -sono: +Linux, seguendo una estensione di BSD, supporta altre due funzioni per la +lettura dello stato di terminazione di un processo \func{wait3} e +\func{wait4}, analoghe alle precedenti ma che prevedono un ulteriore +parametro attraverso il quale il kernel può restituire al padre informazioni +sulle risorse usate dal processo terminato e dai vari figli. I prototipi di +queste funzioni, che diventano accessibili definendo la costante +\macro{\_USE\_BSD}, sono: \begin{functions} \headdecl{sys/times.h} \headdecl{sys/types.h} @@ -1052,8 +1052,9 @@ famiglia di funzioni) che possono essere usate per questo compito, in realt \begin{errlist} \item[\macro{EACCES}] il file non è eseguibile, oppure il filesystem è montato in \cmd{noexec}, oppure non è un file normale o un interprete. - \item[\macro{EPERM}] il file ha i bit \acr{suid} o \acr{sgid} ma l'utente non - è root o il filesystem è montato con \cmd{nosuid}, oppure + \item[\macro{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente non + è root, e o il processo viene tracciato, o il filesystem è montato con + l'opzione \cmd{nosuid}. \item[\macro{ENOEXEC}] il file è in un formato non eseguibile o non riconosciuto come tale, o compilato per un'altra architettura. \item[\macro{ENOENT}] il file o una delle librerie dinamiche o l'interprete @@ -1211,12 +1212,12 @@ speciale può anche non essere resettato a \macro{SIG\_DFL} (si veda \secref{sec:sig_xxx}). -La gestione dei file aperti dipende dal valore del flag di -\textit{close-on-exec} per ciascun file descriptor (si veda -\secref{sec:file_fcntl}); i file per cui è settato vengono chiusi, tutti gli -altri file restano aperti. Questo significa che il comportamento di default è -che i file restano aperti attraverso una \func{exec}, a meno di una chiamata -esplicita a \func{fcntl} che setti il suddetto flag. +La gestione dei file aperti dipende dal valore che ha il flag di +\textit{close-on-exec} (trattato in \secref{sec:file_fcntl}) per ciascun file +descriptor. I file per cui è settato vengono chiusi, tutti gli altri file +restano aperti. Questo significa che il comportamento di default è che i file +restano aperti attraverso una \func{exec}, a meno di una chiamata esplicita a +\func{fcntl} che setti il suddetto flag. Per le directory lo standard POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec}, in genere questo è fatto dalla funzione @@ -1226,9 +1227,9 @@ maniera trasparente all'utente. Abbiamo detto che il \textit{real user id} ed il \textit{real group id} restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per -l'\textit{effective user id} ed l'\textit{effective group id}, tranne il caso -in cui il file che si va ad eseguire ha o il \acr{suid} bit o lo \acr{sgid} -bit settato, nel qual caso \textit{effective user id} e \textit{effective +l'\textit{effective user id} ed l'\textit{effective group id}, tranne quando +il file che si va ad eseguire abbia o il \acr{suid} bit o lo \acr{sgid} bit +settato, in questo caso l'\textit{effective user id} e l'\textit{effective group id} vengono settati rispettivamente all'utente o al gruppo cui il file appartiene (per i dettagli vedi \secref{sec:proc_perms}). @@ -1260,8 +1261,8 @@ parametri connessi ai processi. In questa sezione esamineremo le problematiche relative al controllo di accesso dal punto di vista del processi; vedremo quali sono gli identificatori usati, come questi possono essere modificati nella creazione e nel lancio di -nuovi processi, e le varie funzioni per la loro manipolazione diretta e tutte -le problematiche connesse ad una gestione accorta dei privilegi. +nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le +problematiche connesse ad una gestione accorta dei privilegi. \subsection{Gli identificatori del controllo di accesso} @@ -1294,12 +1295,12 @@ evidente che per poter implementare un controllo sulle operazioni occorre anche poter identificare chi è che ha lanciato un certo programma, e pertanto anche a ciascun processo è associato un utente e a un gruppo. -Un semplice controllo di una corrispondenza fra identificativi però non -garantisce però sufficiente flessibilità per tutti quei casi in cui è -necessario poter disporre di privilegi diversi, o dover impersonare un altro -utente per un limitato insieme di operazioni. Per questo motivo in generale -tutti gli Unix prevedono che i processi abbiano almeno due gruppi di -identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}. +Un semplice controllo di una corrispondenza fra identificativi non garantisce +però sufficiente flessibilità per tutti quei casi in cui è necessario poter +disporre di privilegi diversi, o dover impersonare un altro utente per un +limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix +prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati +rispettivamente \textit{real} ed \textit{effective}. \begin{table}[htb] \footnotesize @@ -1341,8 +1342,8 @@ cui si accede al sistema (e relativo gruppo di default). Servono per l'identificazione dell'utente e normalmente non vengono mai cambiati. In realtà vedremo (in \secref{sec:proc_setuid}) che è possibile modificarli, ma solo ad un processo che abbia i privilegi di amministratore; questa -possibilità è usata ad esempio da \cmd{login} che una volta completata la -procedura di autenticazione lancia una shell per la quale setta questi +possibilità è usata ad esempio da \cmd{login} che, una volta completata la +procedura di autenticazione, lancia una shell per la quale setta questi identificatori ai valori corrispondenti all'utente che entra nel sistema. Al secondo gruppo appartengono l'\textit{effective user id} e @@ -1357,7 +1358,7 @@ Questi identificatori normalmente sono identici ai corrispondenti del gruppo \secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit \acr{suid} o \acr{sgid} settati (il significato di questi bit è affrontato in dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno settati -all'utente e al gruppo proprietari del file; questo consente, per programmi in +all'utente e al gruppo proprietari del file. Questo consente, per programmi in cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi di un'altro (o dell'amministratore). @@ -1447,8 +1448,7 @@ corrente. Il funzionamento di queste due funzioni è analogo, per cui considereremo solo la prima; la seconda si comporta esattamente allo stesso modo facendo riferimento al \textit{group id} invece che all'\textit{user id}. Gli -eventuali \textit{supplementary group id} non vengono modificati da nessuna -delle funzioni che tratteremo in questa sezione. +eventuali \textit{supplementary group id} non vengono modificati. L'effetto della chiamata è diverso a seconda dei privilegi del processo; se @@ -1465,16 +1465,16 @@ riportare l'\textit{effective user id} a quello dell'utente che ha lanciato il programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed eventualmente tornare indietro. -Come esempio per chiarire dell'uso di queste funzioni prediamo quello con cui +Come esempio per chiarire dell'uso di queste funzioni prendiamo quello con cui viene gestito l'accesso al file \file{/var/log/utmp}. In questo file viene registrato chi sta usando il sistema al momento corrente; chiaramente non può essere lasciato aperto in scrittura a qualunque utente, che potrebbe falsificare la registrazione. Per questo motivo questo file (e l'analogo \file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad -esempio tutti i programmi di terminale in X, o il programma \cmd{screen} -che crea terminali multipli su una console) appartengono a questo gruppo ed -hanno il bit \acr{sgid} settato. +esempio tutti i programmi di terminale in X, o il programma \cmd{screen} che +crea terminali multipli su una console) appartengono a questo gruppo ed hanno +il bit \acr{sgid} settato. Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato la situazione degli identificatori è la seguente: @@ -1526,7 +1526,7 @@ ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}). \label{sec:proc_setreuid} Queste due funzioni derivano da BSD che, non supportando\footnote{almeno fino - alla versione 4.3+BSD TODO, verificare e aggiornare la nota.} i + alla versione 4.3+BSD TODO, FIXME verificare e aggiornare la nota.} i \textit{saved id}, le usava per poter scambiare fra di loro \textit{effective} e \textit{real id}. I loro prototipi sono: \begin{functions} @@ -1750,8 +1750,8 @@ ottenere tutti i gruppi a cui appartiene un utente; il suo prototipo restituisce 0 in caso di successo e -1 in caso di fallimento.} \end{functions} \noindent la funzione esegue una scansione del database dei gruppi (si veda -\secref{sec:sys_xxx}) e ritorna in \param{groups} la lista di quelli a cui -l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore +\secref{sec:sys_user_group}) e ritorna in \param{groups} la lista di quelli a +cui l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore perché qualora il valore specificato sia troppo piccolo la funzione ritorna -1 e passando indietro il numero dei gruppi trovati. @@ -1823,11 +1823,10 @@ occorre tenere conto di una serie di problematiche che normalmente non esistono quando si ha a che fare con un sistema in cui viene eseguito un solo programma alla volta. -Pur essendo questo argomento di carattere generale, in questa sezione -conclusiva del capitolo in cui abbiamo affrontato la gestione dei processi ci -è parso opportuno introdurre sinteticamente queste problematiche, che -ritroveremo a più riprese in capitoli successivi, dando una breve descrizione -delle loro caratteristiche principali e della terminologia relativa. +Pur essendo questo argomento di carattere generale, ci è parso opportuno +introdurre sinteticamente queste problematiche, che ritroveremo a più riprese +in capitoli successivi, in questa sezione conclusiva del capitolo in cui +abbiamo affrontato la gestione dei processi. \subsection{Le operazioni atomiche} @@ -1849,7 +1848,7 @@ cui non erano ancora state completate. Nel caso dell'interazione fra processi la situazione è molto più semplice, ed occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in -\capref{cha:IPC}) o nella operazioni con i file (vedremo alcuni esempi in +\capref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in \secref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate funzioni di libreria per compiere le operazioni necessarie è garanzia sufficiente di atomicità in quanto le system call con cui esse sono realizzate @@ -1865,13 +1864,13 @@ operazioni atomiche (torneremo su questi aspetti in \secref{sec:sign_xxx}). In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t}, il cui accesso è assicurato essere atomico. In pratica comunque si può -assumere che in ogni piattaforma su cui è implementato Linux il tipo -\type{int} (e gli altri interi di dimensione inferiore) ed i puntatori sono +assumere che, in ogni piattaforma su cui è implementato Linux, il tipo +\type{int}, gli altri interi di dimensione inferiore ed i puntatori sono atomici. Non è affatto detto che lo stesso valga per interi di dimensioni maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per -le strutture. In questi casi è anche opportuno marcare come \type{volatile} le -variabili che possono essere interessate ad accesso condiviso, onde evitare -problemi con le ottimizzazioni del codice. +le strutture. In tutti questi casi è anche opportuno marcare come +\type{volatile} le variabili che possono essere interessate ad accesso +condiviso, onde evitare problemi con le ottimizzazioni del codice. \subsection{Le \textit{race condition} e i \textit{deadlock}} @@ -1880,7 +1879,7 @@ problemi con le ottimizzazioni del codice. Si definiscono \textit{race condition} tutte quelle situazioni in cui processi diversi operano su una risorsa comune, ed in cui il risultato viene a dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso -tipico è quella di una operazione che viene eseguita da un processo in più +tipico è quello di una operazione che viene eseguita da un processo in più passi, e può essere compromessa dall'intervento di un altro processo che accede alla stessa risorsa quando ancora non tutti i passi sono stati completati. @@ -1900,8 +1899,8 @@ gli adeguati provvedimenti per far si che non si verifichino. Casi tipici di file, o nell'accesso a meccanismi di intercomunicazione come la memoria condivisa. In questi casi, se non si dispone della possibilità di eseguire atomicamente le operazioni necessarie, occorre che quelle parti di codice in -cui si compiono le operazioni critiche sulle risorse condivise, le cosiddette -\textsl{sezioni critiche} del programma, siano opportunamente protette da +cui si compiono le operazioni sulle risorse condivise (le cosiddette +\textsl{sezioni critiche}) del programma, siano opportunamente protette da meccanismi di sincronizzazione (torneremo su queste problematiche di questo tipo in \secref{sec:ipc_semaph}). @@ -1919,8 +1918,7 @@ quest'ultima diventer In tutti questi casi è di fondamentale importanza il concetto di atomicità visto in \secref{sec:proc_atom_oper}; questi problemi infatti possono essere risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile -eseguire in maniera atomica le operazioni necessarie, proteggendo con gli -adeguati meccanismi le \textsl{sezioni critiche} del programma. +eseguire in maniera atomica le operazioni necessarie. \subsection{Le funzioni rientranti}