From: Simone Piccardi Date: Mon, 9 Jan 2012 23:24:45 +0000 (+0000) Subject: Modifiche figure per uso del font inconsolata e ulteriore revisione X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=9ae76fdeacb0ff52559c8bf310b20d485ccc9328;p=gapil.git Modifiche figure per uso del font inconsolata e ulteriore revisione del quarto capitolo. --- diff --git a/filedir.tex b/filedir.tex index 1964e7d..9cd3f89 100644 --- a/filedir.tex +++ b/filedir.tex @@ -42,7 +42,7 @@ successori. \subsection{Il funzionamento del \textit{Virtual File System} di Linux} \label{sec:file_vfs_work} -% articolo interessante: +% NOTE articolo interessante: % http://www.ibm.com/developerworks/linux/library/l-virtual-filesystem-switch/index.html?ca=dgr-lnxw97Linux-VFSdth-LXdW&S_TACT=105AGX59&S_CMP=GRlnxw97 \itindbeg{Virtual~File~System} @@ -55,6 +55,8 @@ tutti i filesystem devono implementare per l'accesso ai file che contengono e l'interfaccia che consente di eseguire l'I/O sui file, che questi siano di dati o dispositivi. +\itindbeg{inode} + L'interfaccia fornita dal VFS comprende in sostanza tutte le funzioni che riguardano i file, le operazioni implementate dal VFS sono realizzate con una astrazione che prevede quattro tipi di oggetti strettamente correlati: i @@ -63,7 +65,7 @@ corrispondono una serie di apposite strutture definite dal kernel che contengono come campi le funzioni di gestione e realizzano l'infrastruttura del VFS. L'interfaccia è molto complessa, ne faremo pertanto una trattazione estremamente semplificata che consenta di comprenderne i principi -difunzionamento. +di funzionamento. Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun filesystem supportato, quando si vuole inserire il supporto di un nuovo @@ -97,6 +99,8 @@ filesystem si dovrà allocare una di queste strutture ed inizializzare i relativi campi con i dati specifici di quel filesystem, ed in particolare si dovrà creare anche la relativa versione della funzione \code{mount}. +\itindbeg{pathname} + Come illustrato in fig.~\ref{fig:kstruct_file_system_type} questa funzione restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory entry}. Le \textit{dentry} sono gli oggetti che il kernel usa per eseguire @@ -124,12 +128,12 @@ Dato che normalmente non è possibile mantenere nella \textit{dcache} le informazioni relative a tutto l'albero dei file la procedura della \textit{pathname resolution} richiede un meccanismo con cui riempire gli eventuali vuoti. Il meccanismo prevede che tutte le volte che si arriva ad una -\textit{dentry} mancante venga invocata la funzione \texttt{lookup} dell'inode -associato alla \textit{dentry} precedente nella risoluzione del -\textit{pathname},\footnote{che a questo punto è una directory, per cui si può - cercare al suo interno il nome di un file.} il cui scopo è risolvere il nome -mancante e fornire la sua \textit{dentry} che a questo punto verrà inserita -nella cache. +\textit{dentry} mancante venga invocata la funzione \texttt{lookup} +dell'\textit{inode} associato alla \textit{dentry} precedente nella +risoluzione del \textit{pathname},\footnote{che a questo punto è una + directory, per cui si può cercare al suo interno il nome di un file.} il cui +scopo è risolvere il nome mancante e fornire la sua \textit{dentry} che a +questo punto verrà inserita nella cache. Dato che tutte le volte che si monta un filesystem la funzione \texttt{mount} della corrispondente \kstruct{file\_system\_type} inserisce la \textit{dentry} @@ -140,6 +144,8 @@ filesystem, e come vedremo questo farà sì che venga eseguita una \texttt{lookup} adatta per effettuare la risoluzione dei nomi per quel filesystem. +\itindend{pathname} + % Un secondo effetto della chiamata funzione \texttt{mount} di % \kstruct{file\_system\_type} è quello di allocare una struttura % \kstruct{super\_block} per ciascuna istanza montata, che contiene le @@ -267,6 +273,8 @@ questo può essere anche un file di dispositivo, ed in questo caso il VFS invece di usare le operazioni fornite dal filesystem (come farebbe per un file di dati) dovrà invece ricorrere a quelle fornite dal driver del dispositivo. +\itindend{inode} + \begin{figure}[!htb] \footnotesize \centering \begin{minipage}[c]{\textwidth} @@ -342,6 +350,10 @@ esserci negli oggetti a cui si applicano. \itindend{Virtual~File~System} +% NOTE: documentazione interessante: +% * sorgenti del kernel: Documentation/filesystems/vfs.txt +% * http://thecoffeedesk.com/geocities/rkfs.html +% * http://www.linux.it/~rubini/docs/vfs/vfs.html \subsection{Il funzionamento di un filesystem Unix} \label{sec:file_filesystem} @@ -366,13 +378,15 @@ sottostanti) e creata una opportuna suddivisione dei dati e delle informazioni per accedere agli stessi. Sulle caratteristiche di \acr{ext2} e derivati torneremo in sez.~\ref{sec:file_ext2}. +\itindbeg{inode} + È comunque caratteristica comune di tutti i filesystem per Unix, indipendentemente da come poi viene strutturata nei dettagli questa informazione, prevedere la presenza di due tipi di risorse: gli -\itindex{inode} \textit{inode}, cui abbiamo già accennato in -sez.~\ref{sec:file_vfs_work}, che sono le strutture che identificano i singoli -oggetti sul filesystem, e i blocchi, che invece attengono allo spazio disco -che viene messo a disposizione per i dati in essi contenuti. +\textit{inode}, cui abbiamo già accennato in sez.~\ref{sec:file_vfs_work}, che +sono le strutture che identificano i singoli oggetti sul filesystem, e i +blocchi, che invece attengono allo spazio disco che viene messo a disposizione +per i dati in essi contenuti. \begin{figure}[!htb] \centering @@ -391,7 +405,7 @@ esposto in fig.~\ref{fig:file_filesys_detail}. \begin{figure}[!htb] \centering - \includegraphics[width=14cm]{img/filesys_struct} + \includegraphics[width=12cm]{img/filesys_struct} \caption{Strutturazione dei dati all'interno di un filesystem.} \label{fig:file_filesys_detail} \end{figure} @@ -404,101 +418,115 @@ per capire il funzionamento delle funzioni che manipolano i file e le directory che tratteremo nel prosieguo del capitolo. In particolare è opportuno tenere sempre presente che: + \begin{enumerate} -\item L'\textit{inode} \itindex{inode} contiene tutte le informazioni, i - cosiddetti \textsl{metadati}, riguardanti il file: il tipo di file, i - permessi di accesso, le dimensioni, i puntatori ai blocchi fisici che - contengono i dati e così via. Le informazioni che la funzione \func{stat} - (vedi sez.~\ref{sec:file_stat}) fornisce provengono dall'\textit{inode}. - Dentro una directory si troverà solo il nome del file e il numero - \itindex{inode} dell'\textit{inode} ad esso associato, cioè quella che da - qui in poi chiameremo una \textsl{voce}, che abbiamo scelto come traduzione - dell'inglese \textit{directory entry}, che non useremo anche per evitare - confusione con le \textit{dentry} del kernel di cui si parlava in - sez.~\ref{sec:file_vfs_work}. +\item L'\textit{inode} contiene i cosiddetti \textsl{metadati}, vale dire le + informazioni riguardanti le proprietà del file come oggetto del filesystem: + il tipo di file, i permessi di accesso, le dimensioni, i puntatori ai + blocchi fisici che contengono i dati e così via. Le informazioni che la + funzione \func{stat} (vedi sez.~\ref{sec:file_stat}) fornisce provengono + dall'\textit{inode}. Dentro una directory si troverà solo il nome del file + e il numero dell'\textit{inode} ad esso associato; il nome non è una + proprietà del file e non viene mantenuto nell'\textit{inode}. Da da qui in + poi chiameremo il nome del file contenuto in una directory + ``\textsl{voce}'', come traduzione della nomenclatura inglese + \textit{directory entry} che non useremo per evitare confusione con le + \textit{dentry} del kernel viste in sez.~\ref{sec:file_vfs_work}. -\item Come mostrato in fig.~\ref{fig:file_filesys_detail} si possono avere più - voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un - contatore che contiene il numero di riferimenti che sono stati fatti ad esso - (il cosiddetto \textit{link count}); solo quando questo contatore si annulla - i dati del file vengono effettivamente rimossi dal disco. Per questo la - funzione per cancellare un file si chiama \func{unlink} (vedi - sez.~\ref{sec:file_link}), ed in realtà non cancella affatto i dati del - file, ma si limita ad eliminare la relativa voce da una directory e - decrementare il numero di riferimenti \itindex{inode} nell'\textit{inode}. +\item Come mostrato in fig.~\ref{fig:file_filesys_detail} per i file + \texttt{macro.tex} e \texttt{gapil\_macro.tex}, ci possono avere più voci + che fanno riferimento allo stesso \textit{inode}. Fra le proprietà di un + file mantenute nell'\textit{inode} c'è anche il contatore con il numero di + riferimenti che sono stati fatti ad esso, il cosiddetto \textit{link + count}.\footnote{mantenuto anche nel campo \var{i\_nlink} della struttura + \kstruct{inode} di fig.~\ref{fig:kstruct_inode}.} Solo quando questo + contatore si annulla i dati del file possono essere effettivamente rimossi + dal disco. Per questo la funzione per cancellare un file si chiama + \func{unlink} (vedi sez.~\ref{sec:file_link}), ed in realtà non cancella + affatto i dati del file, ma si limita ad eliminare la relativa voce da una + directory e decrementare il numero di riferimenti nell'\textit{inode}. \item All'interno di ogni filesystem ogni \textit{inode} è identificato da un - numero univoco. Il numero di \textit{inode} nella voce si riferisce ad un - \textit{inode} a questo numero e non ci può essere una directory che - contiene riferimenti ad \itindex{inode} \textit{inode} relativi ad altri - filesystem. Questo limita l'uso del comando \cmd{ln} (che crea una nuova - voce per un file esistente con la funzione \func{link}) al filesystem - corrente. + numero univoco. Il numero di \textit{inode} associato ad una voce in una + directory si riferisce ad questo numero e non ci può essere una directory + che contiene riferimenti ad \textit{inode} relativi ad altri filesystem. + Questa è la ragione che limita l'uso del comando \cmd{ln}, che crea una + nuova voce per un file esistente con la funzione \func{link} (vedi + sez.~\ref{sec:file_link}) a file nel filesystem corrente. -\item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto +\item Quando si cambia nome ad un file senza cambiare filesystem il contenuto del file non viene spostato fisicamente, viene semplicemente creata una - nuova voce per \itindex{inode} l'\textit{inode} in questione e rimossa la - vecchia (questa è la modalità in cui opera normalmente il comando \cmd{mv} - attraverso la funzione \func{rename}, vedi - sez.~\ref{sec:file_remove}). Questa operazione non modifica minimamente - neanche l'\textit{inode} del file dato che non si opera su questo ma sulla - directory che lo contiene. + nuova voce per l'\textit{inode} in questione e rimossa la precedente, questa + è la modalità in cui opera normalmente il comando \cmd{mv} attraverso la + funzione \func{rename} (vedi sez.~\ref{sec:file_remove}). Questa operazione + non modifica minimamente neanche l'\textit{inode} del file, dato che non si + opera su questo ma sulla directory che lo contiene. \item Gli \textit{inode} dei file, che contengono i \textsl{metadati} ed i blocchi di spazio disco, che contengono i dati, sono risorse indipendenti ed in genere vengono gestite come tali anche dai diversi filesystem; è pertanto - possibile sia esaurire lo spazio disco (caso più comune) che lo spazio per - gli \textit{inode}, nel primo caso non sarà possibile allocare ulteriore + possibile esaurire sia lo spazio disco (il caso più comune) che lo spazio + per gli \textit{inode}. Nel primo caso non sarà possibile allocare ulteriore spazio, ma si potranno creare file (vuoti), nel secondo non si potranno - creare nuovi file, ma si potranno estendere quelli che ci sono. + creare nuovi file, ma si potranno estendere quelli che ci + sono.\footnote{questo comportamento non è generale, alcuni filesystem evoluti + possono evitare il problema dell'esaurimento degli \textit{inode} + riallocando lo spazio disco libero per i blocchi.} \end{enumerate} -Infine si noti che, essendo file pure loro, il numero di riferimenti esiste -anche per le directory; per cui, se a partire dalla situazione mostrata in -fig.~\ref{fig:file_filesys_detail} creiamo una nuova directory \file{img} -nella directory \file{gapil}, avremo una situazione come quella in -fig.~\ref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri -di \itindex{inode} inode. - \begin{figure}[!htb] \centering - \includegraphics[width=14cm]{img/dir_links} + \includegraphics[width=12cm]{img/dir_links} \caption{Organizzazione dei \textit{link} per le directory.} \label{fig:file_dirs_link} \end{figure} -La nuova directory avrà allora un numero di riferimenti pari a due, in quanto -è referenziata dalla directory da cui si era partiti (in cui è inserita la -nuova voce che fa riferimento a \texttt{img}) e dalla voce ``\texttt{.}'' che -è sempre inserita in ogni directory; questo vale sempre per ogni directory che -non contenga a sua volta altre directory. Al contempo, la directory da cui si -era partiti avrà un numero di riferimenti di almeno tre, in quanto adesso sarà -referenziata anche dalla voce ``\texttt{..}'' di \texttt{img}. +Infine tenga presente che, essendo file pure loro, il numero di riferimenti +esiste anche per le directory. Per questo se a partire dalla situazione +mostrata in fig.~\ref{fig:file_filesys_detail} creiamo una nuova directory +\file{img} nella directory \file{gapil}, avremo una situazione come quella +illustrata in fig.~\ref{fig:file_dirs_link}. +La nuova directory avrà un numero di riferimenti pari a due, in quanto è +referenziata dalla directory da cui si era partiti (in cui è inserita la nuova +voce che fa riferimento a \texttt{img}) e dalla voce interna ``\texttt{.}'' +che è presente in ogni directory. Questo è il valore che si troverà sempre +per ogni directory che non contenga a sua volta altre directory. Al contempo, +la directory da cui si era partiti avrà un numero di riferimenti di almeno +tre, in quanto adesso sarà referenziata anche dalla voce ``\texttt{..}'' di +\texttt{img}. L'aggiunta di una sottodirectory fa cioè crescere di uno il +\textit{link count} della directory genitrice. -\subsection{I filesystem di uso comune} +\itindend{inode} + + +\subsection{Alcuni dettagli sul filesystem \textsl{ext2} e successori} \label{sec:file_ext2} -Il filesystem standard più usato con Linux è il cosiddetto \textit{third - extended filesystem}, identificato dalla sigla \acr{ext3}.\footnote{si fa - riferimento al momento della stesura di questo paragrafo, l'inizio del - 2010.} Esso nasce come evoluzione del precedente \textit{second extended - filesystem}, o \acr{ext2}, di cui eredita gran parte delle caratteristiche -di base, per questo motivo parleremo anzitutto di questo, dato che molto di -quanto diremo si applica anche ad \acr{ext3}. A partire dal kernel 2.6.XX è -stato dichiarato stabile il nuovo filsesystem \textit{ext4}, ulteriore -evoluzione di \textit{ext3} dotato di molte caratteristiche avanzate, che sta -iniziando a sostituirlo gradualmente. - -Il filesystem \acr{ext2} nasce come filesystem nativo di Linux a partire dalle -prime versioni del kernel e supporta tutte le caratteristiche di un filesystem -standard Unix: è in grado di gestire nomi di file lunghi (256 caratteri, -estensibili a 1012) e supporta una dimensione massima dei file fino a 4~Tb. I -successivi filesystem \acr{ext3} ed \acr{ext4} sono evoluzioni di questo -filesystem, e sia pure con molti miglioramenti ed estensioni significative ne -mantengono in sostanza le caratteristiche fondamentali. + +Benché non esista il filesystem di Linux, dato che esiste un supporto nativo +di diversi filesystem che sono in uso da anni, quello che gli avvicina di più +è la famiglia di filesystem evolutasi a partire dal \textit{second extended + filesystem}, o \acr{ext2}, che nonostante il nome è stato il primo ad essere +usato in maniera estensiva. Il filesystem \acr{ext2} ha subito un grande +sviluppo e diverse evoluzioni, fra cui l'aggiunta del \textit{journaling} con +\acr{ext3}, probabilmente ancora il filesystem più diffuso, ed una serie di +ulteriori miglioramento con il successivo \acr{ext4}, che sta iniziando a +sostituirlo gradualmente. In futuro è previsto che questo debba essere +sostituito da un filesystem completamente diverso, \acr{btrfs}, che dovrebbe +diventare il filesystem standard di Linux, ma questo al momento è ancora in +fase di sviluppo.\footnote{si fa riferimento al momento dell'ultima revisione + di di questo paragrafo, l'inizio del 2012.} + +Il filesystem \acr{ext2} nasce come filesystem nativo per Linux a partire +dalle prime versioni del kernel e supporta tutte le caratteristiche di un +filesystem standard Unix: è in grado di gestire nomi di file lunghi (256 +caratteri, estensibili a 1012) e supporta una dimensione massima dei file fino +a 4~Tb. I successivi filesystem \acr{ext3} ed \acr{ext4} sono evoluzioni di +questo filesystem, e sia pure con molti miglioramenti ed estensioni +significative ne mantengono le caratteristiche fondamentali. Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che non sono presenti su un classico filesystem di tipo Unix; le principali sono @@ -517,12 +545,13 @@ le seguenti: questi termini si veda sez.~\ref{sec:file_access_control}), nel qual caso file e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}. \item l'amministratore può scegliere la dimensione dei blocchi del filesystem - in fase di creazione, a seconda delle sue esigenze (blocchi più grandi - permettono un accesso più veloce, ma sprecano più spazio disco). + in fase di creazione, a seconda delle sue esigenze: blocchi più grandi + permettono un accesso più veloce, ma sprecano più spazio disco. \item il filesystem implementa link simbolici veloci, in cui il nome del file - non è salvato su un blocco, ma tenuto all'interno \itindex{inode} dell'inode - (evitando letture multiple e spreco di spazio), non tutti i nomi però - possono essere gestiti così per limiti di spazio (il limite è 60 caratteri). + non è salvato su un blocco, ma tenuto all'interno \itindex{inode} + dell'\textit{inode} (evitando letture multiple e spreco di spazio), non + tutti i nomi però possono essere gestiti così per limiti di spazio (il + limite è 60 caratteri). \item vengono supportati i file immutabili (che possono solo essere letti) per la protezione di file di configurazione sensibili, o file \textit{append-only} che possono essere aperti in scrittura solo per @@ -533,25 +562,19 @@ le seguenti: La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD: un filesystem è composto da un insieme di blocchi, la struttura generale è quella riportata in fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa -in gruppi di blocchi.\footnote{non si confonda questa definizione con - quella riportata in fig.~\ref{fig:file_dirent_struct}; in quel caso si fa - riferimento alla struttura usata in user space per riportare i dati - contenuti in una directory generica, questa fa riferimento alla struttura - usata dal kernel per un filesystem \acr{ext2}, definita nel file - \texttt{ext2\_fs.h} nella directory \texttt{include/linux} dei sorgenti del - kernel.} +in gruppi di blocchi. Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del -filesystem (superblock e descrittore del filesystem sono quindi ridondati) per -una maggiore affidabilità e possibilità di recupero in caso di corruzione del -superblock principale. L'utilizzo di raggruppamenti di blocchi ha inoltre -degli effetti positivi nelle prestazioni dato che viene ridotta la distanza -fra i dati e la tabella degli \itindex{inode} inode. +filesystem (i \textit{superblock} sono quindi ridondati) per una maggiore +affidabilità e possibilità di recupero in caso di corruzione del +\textit{superblock} principale. L'utilizzo di raggruppamenti di blocchi ha +inoltre degli effetti positivi nelle prestazioni dato che viene ridotta la +distanza fra i dati e la tabella degli \itindex{inode} inode. \begin{figure}[!htb] \centering \includegraphics[width=9cm]{img/dir_struct} - \caption{Struttura delle directory nel \textit{second extented filesystem}.} + \caption{Struttura delle directory nel \textit{second extended filesystem}.} \label{fig:file_ext2_dirs} \end{figure} @@ -562,12 +585,12 @@ lunghezza, secondo lo schema in fig.~\ref{fig:file_ext2_dirs}; in questo modo è possibile implementare nomi per i file anche molto lunghi (fino a 1024 caratteri) senza sprecare spazio disco. -Con l'introduzione del filesystem \textit{ext3} sono state introdotte anche -alcune modifiche strutturali, la principale di queste è quella che -\textit{ext3} è un filesystem \textit{jounrnaled}, è cioè in grado di eseguire -una registrazione delle operazioni di scrittura su un giornale (uno speciale -file interno) in modo da poter garantire il ripristino della coerenza dei dati -del filesystem\footnote{si noti bene che si è parlato di dati \textsl{del} +Con l'introduzione del filesystem \textit{ext3} sono state introdotte diverse +modifiche strutturali, la principale di queste è quella che \textit{ext3} è un +filesystem \textit{journaled}, è cioè in grado di eseguire una registrazione +delle operazioni di scrittura su un giornale (uno speciale file interno) in +modo da poter garantire il ripristino della coerenza dei dati del +filesystem\footnote{si noti bene che si è parlato di dati \textsl{del} filesystem, non di dati \textsl{nel} filesystem, quello di cui viene garantito un veloce ripristino è relativo ai dati della struttura interna del filesystem, non di eventuali dati contenuti nei file che potrebbero @@ -578,9 +601,9 @@ della scrittura dei dati sul disco. Oltre a questo \textit{ext3} introduce ulteriori modifiche volte a migliorare sia le prestazioni che la semplicità di gestione del filesystem, in particolare per le directory si è passato all'uso di alberi binari con -indicizzazione tramite hash al posto delle \textit{linked list}, ottenendo un -forte guadagno di prestazioni in caso di directory contenenti un gran numero -di file. +indicizzazione tramite hash al posto delle \textit{linked list} che abbiamo +illustrato, ottenendo un forte guadagno di prestazioni in caso di directory +contenenti un gran numero di file. % TODO portare a ext3, ext4 e btrfs ed illustrare le problematiche che si % possono incontrare (in particolare quelle relative alla perdita di contenuti @@ -593,67 +616,88 @@ di file. Come accennato in sez.~\ref{sec:file_arch_overview} per poter accedere ai file occorre prima rendere disponibile al sistema il filesystem su cui essi sono memorizzati; l'operazione di attivazione del filesystem è chiamata -\textsl{montaggio}, per far questo in Linux\footnote{la funzione è specifica - di Linux e non è portabile.} si usa la funzione \funcd{mount} il cui -prototipo è: -\begin{prototype}{sys/mount.h} -{mount(const char *source, const char *target, const char *filesystemtype, - unsigned long mountflags, const void *data)} +\textsl{montaggio}, per far questo in Linux si usa la funzione \funcd{mount} +il cui prototipo è:\footnote{la funzione è una versione specifica di Linux e + non è portabile.} + +\begin{funcproto}{ +\fhead{sys/mount.h} +\fdecl{mount(const char *source, const char *target, const char + *filesystemtype, \\ +\phantom{mount(}unsigned long mountflags, const void *data)} +\fdesc{Monta un filesystem.} +} -Monta il filesystem di tipo \param{filesystemtype} contenuto in \param{source} -sulla directory \param{target}. - - \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di - fallimento, nel qual caso gli errori comuni a tutti i filesystem che possono - essere restituiti in \var{errno} sono: +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual + caso \var{errno} assumerà uno dei valori: \begin{errlist} - \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore. - \item[\errcode{ENODEV}] \param{filesystemtype} non esiste o non è configurato - nel kernel. - \item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per - \param{source} quando era richiesto. + \item[\errcode{EACCES}] non si ha il permesso di accesso su uno dei + componenti del \itindex{pathname} \textit{pathname}, o si è cercato di + montare un filesystem disponibile in sola lettura senza aver specificato + \const{MS\_RDONLY} o il device \param{source} è su un filesystem montato + con l'opzione \const{MS\_NODEV}. \item[\errcode{EBUSY}] \param{source} è già montato, o non può essere - rimontato in read-only perché ci sono ancora file aperti in scrittura, o - \param{target} è ancora in uso. - \item[\errcode{EINVAL}] il device \param{source} presenta un + rimontato in sola lettura perché ci sono ancora file aperti in scrittura, + o non può essere montato su \param{target} perché la directory è ancora in + uso. + \item[\errcode{EINVAL}] il dispositivo \param{source} presenta un \textit{superblock} non valido, o si è cercato di rimontare un filesystem non ancora montato, o di montarlo senza che \param{target} sia un \itindex{mount~point} \textit{mount point} o di spostarlo quando \param{target} non è un \itindex{mount~point} \textit{mount point} - o è \file{/}. - \item[\errcode{EACCES}] non si ha il permesso di accesso su uno dei - componenti del \itindex{pathname} \textit{pathname}, o si è cercato - di montare un filesystem disponibile in sola lettura senza averlo - specificato o il device \param{source} è su un filesystem montato con - l'opzione \const{MS\_NODEV}. - \item[\errcode{ENXIO}] il \itindex{major~number} \textit{major number} del - device \param{source} è sbagliato. + o è la radice. \item[\errcode{EMFILE}] la tabella dei device \textit{dummy} è piena. - \end{errlist} - ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM}, - \errval{ENAMETOOLONG}, \errval{ENOENT} o \errval{ELOOP}.} -\end{prototype} - -La funzione monta sulla directory \param{target}, detta \itindex{mount~point} -\textit{mount point}, il filesystem contenuto in \param{source}. In generale -un filesystem è contenuto su un disco, e l'operazione di montaggio corrisponde -a rendere visibile al sistema il contenuto del suddetto disco, identificato -attraverso il file di dispositivo ad esso associato. + \item[\errcode{ENODEV}] il tipo \param{filesystemtype} non esiste o non è + configurato nel kernel. + \item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per + \param{source} quando era richiesto. + \item[\errcode{ENXIO}] il \itindex{major~number} \textit{major number} del + dispositivo \param{source} è sbagliato. + \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore. + \end{errlist} + ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{ENOMEM}, + \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOTDIR} nel loro + significato generico.} +\end{funcproto} + +La funzione monta sulla directory indicata \param{target}, detta +\itindex{mount~point} \textit{mount point}, il filesystem contenuto nel file +di dispositivo indicato \param{source}. In entrambi i casi, come daremo per +assunto da qui in avanti tutte le volte che si parla di directory o file nel +passaggio di un argomento di una funzione, si intende che questi devono essere +indicati con la stringa contenente il loro \itindex{pathname} +\textit{pathname}. + +In generale un filesystem è contenuto su un disco, e come illustrato in +sez.~\ref{sec:file_vfs_work} l'operazione di montaggio corrisponde a rendere +visibile il contenuto del suddetto disco, identificato attraverso il file di +dispositivo ad esso associato, all'interno di una directory dell'albero dei +file. Ma la struttura del \textit{Virtual File System} vista in -sez.~\ref{sec:file_vfs_work} è molto più flessibile e può essere usata anche -per oggetti diversi da un disco. Ad esempio usando il \textit{loop device} si -può montare un file qualunque (come l'immagine di un CD-ROM o di un floppy) -che contiene un filesystem, inoltre alcuni filesystem, come \file{proc} o -\file{devfs} sono del tutto virtuali, i loro dati sono generati al volo ad -ogni lettura, e passati al kernel ad ogni scrittura. - -Il tipo di filesystem è specificato da \param{filesystemtype}, che deve essere -una delle stringhe riportate nel file \procfile{/proc/filesystems}, che -contiene l'elenco dei filesystem supportati dal kernel; nel caso si sia -indicato uno dei filesystem virtuali, il contenuto di \param{source} viene +sez.~\ref{sec:file_vfs_work} è estremamente flessibile e può essere usata +anche per oggetti diversi da un disco. Ad esempio usando il \textit{loop + device} si può montare un file qualunque (come l'immagine di un CD-ROM o di +un floppy) che contiene un filesystem, inoltre alcuni filesystem, come +\file{proc} o \file{devfs} sono del tutto virtuali, i loro dati sono generati +al volo ad ogni lettura, e passati al kernel ad ogni scrittura. + +Il tipo di filesystem è specificato dall'argomento \param{filesystemtype}, che +deve essere una delle stringhe riportate nel file +\procfile{/proc/filesystems}, che come accennato in +sez.~\ref{sec:file_vfs_work} contiene l'elenco dei filesystem supportati dal +kernel. Nel caso si sia indicato uno dei filesystem virtuali, che non è +associato a nessun file di dispositivo, il contenuto di \param{source} viene ignorato. +L'argomento \param{data} viene usato per passare le impostazioni relative alle +caratteristiche specifiche di ciascun filesystem. Si tratta di una stringa di +parole chiave (separate da virgole e senza spazi) che indicano le opzioni del +filesytem che devono essere impostate, in sostanza viene usato il contenuto +del parametro dell'opzione \texttt{-o} del comando \texttt{mount}. I valori +utilizzabili dipendono dal tipo di filesystem e ciascuno ha i suoi, pertanto +si rimanda alla documentazione della pagina di manuale di questo comando. + Dopo l'esecuzione della funzione il contenuto del filesystem viene resto disponibile nella directory specificata come \itindex{mount~point} \textit{mount point}, il precedente contenuto di detta directory viene @@ -663,8 +707,8 @@ Dal kernel 2.4.x inoltre è divenuto possibile sia spostare atomicamente un \itindex{mount~point} \textit{mount point} da una directory ad un'altra, sia montare in diversi \itindex{mount~point} \textit{mount point} lo stesso filesystem, sia montare più filesystem sullo stesso \itindex{mount~point} -\textit{mount point} (nel qual caso vale quanto appena detto, e solo il -contenuto dell'ultimo filesystem montato sarà visibile). +\textit{mount point}, nel qual caso vale quanto appena detto, e solo il +contenuto dell'ultimo filesystem montato sarà visibile. Ciascun filesystem è dotato di caratteristiche specifiche che possono essere attivate o meno, alcune di queste sono generali (anche se non è detto siano @@ -683,7 +727,7 @@ valori riportati in tab.~\ref{tab:sys_mount_flags}. \begin{table}[htb] \footnotesize \centering - \begin{tabular}[c]{|l|r|l|} + \begin{tabular}[c]{|l|r|p{8cm}|} \hline \textbf{Parametro} & \textbf{Valore}&\textbf{Significato}\\ \hline @@ -719,10 +763,6 @@ valori riportati in tab.~\ref{tab:sys_mount_flags}. % gli S_* non esistono più come segnalato da Alessio... % verificare i readonly mount bind del 2.6.26 -Per l'impostazione delle caratteristiche particolari di ciascun filesystem si -usa invece l'argomento \param{data} che serve per passare le ulteriori -informazioni necessarie, che ovviamente variano da filesystem a filesystem. - La funzione \func{mount} può essere utilizzata anche per effettuare il \textsl{rimontaggio} di un filesystem, cosa che permette di cambiarne al volo alcune delle caratteristiche di funzionamento (ad esempio passare da sola @@ -734,28 +774,32 @@ viene ignorato. Una volta che non si voglia più utilizzare un certo filesystem è possibile \textsl{smontarlo} usando la funzione \funcd{umount}, il cui prototipo è: -\begin{prototype}{sys/mount.h}{umount(const char *target)} - - Smonta il filesystem montato sulla directory \param{target}. - - \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di - fallimento, nel qual caso \var{errno} assumerà uno dei valori: + +\begin{funcproto}{ +\fhead{sys/mount.h} +\fdecl{umount(const char *target)} +\fdesc{Smonta un filesystem.} +} +{La funzione ritorna $0$ in caso + di successo e $-1$ per un errore, + nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore. \item[\errcode{EBUSY}] \param{target} è la directory di lavoro di qualche processo, o contiene dei file aperti, o un altro mount point. - \end{errlist} - ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM}, - \errval{ENAMETOOLONG}, \errval{ENOENT} o \errval{ELOOP}.} -\end{prototype} -\noindent la funzione prende il nome della directory su cui il filesystem è -montato e non il file o il dispositivo che è stato montato,\footnote{questo è - vero a partire dal kernel 2.3.99-pre7, prima esistevano due chiamate - separate e la funzione poteva essere usata anche specificando il file di - dispositivo.} in quanto con il kernel 2.4.x è possibile montare lo stesso -dispositivo in più punti. Nel caso più di un filesystem sia stato montato -sullo stesso \itindex{mount~point} \textit{mount point} viene smontato quello -che è stato montato per ultimo. +\end{errlist}ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM}, +\errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ELOOP} nel loro + significato generico.} +\end{funcproto} + +La funzione prende il nome della directory su cui il filesystem è montato e +non il file o il dispositivo che è stato montato,\footnote{questo è vero a + partire dal kernel 2.3.99-pre7, prima esistevano due chiamate separate e la + funzione poteva essere usata anche specificando il file di dispositivo.} in +quanto con il kernel 2.4.x è possibile montare lo stesso dispositivo in più +punti. Nel caso più di un filesystem sia stato montato sullo stesso +\itindex{mount~point} \textit{mount point} viene smontato quello che è stato +montato per ultimo. Si tenga presente che la funzione fallisce quando il filesystem è \textsl{occupato}, questo avviene quando ci sono ancora file aperti sul @@ -766,11 +810,14 @@ filesystem; in questo caso l'errore restituito è \errcode{EBUSY}. Linux provvede inoltre una seconda funzione, \funcd{umount2}, che in alcuni casi permette di forzare lo smontaggio di un filesystem, anche quando questo risulti occupato; il suo prototipo è: -\begin{prototype}{sys/mount.h}{umount2(const char *target, int flags)} - - La funzione è identica a \func{umount} per comportamento e codici di errore, - ma con \param{flags} si può specificare se forzare lo smontaggio. -\end{prototype} +\begin{funcproto}{ +\fhead{sys/mount.h} +\fdecl{umount2(const char *target, int flags)} +\fdesc{Smonta un filesystem.} +} +{La funzione è identica a \func{umount} per valori di ritorno e codici di + errore. } +\end{funcproto} Il valore di \param{flags} è una maschera binaria, e al momento l'unico valore definito è il bit \const{MNT\_FORCE}; gli altri bit devono essere nulli. @@ -786,25 +833,23 @@ Altre due funzioni specifiche di Linux,\footnote{esse si trovano anche su BSD, ma con una struttura diversa.} utili per ottenere in maniera diretta informazioni riguardo al filesystem su cui si trova un certo file, sono \funcd{statfs} e \funcd{fstatfs}, i cui prototipi sono: -\begin{functions} - \headdecl{sys/vfs.h} - \funcdecl{int statfs(const char *path, struct statfs *buf)} - \funcdecl{int fstatfs(int fd, struct statfs *buf)} - - Restituisce in \param{buf} le informazioni relative al filesystem su cui è - posto il file specificato. - - \bodydesc{Le funzioni ritornano 0 in caso di successo e -1 in caso di - errore, nel qual caso \var{errno} assumerà uno dei valori: +\begin{funcproto}{ +\fhead{sys/vfs.h} +\fdecl{int statfs(const char *path, struct statfs *buf)} +\fdecl{int fstatfs(int fd, struct statfs *buf)} +\fdesc{Restituiscono informazioni relative ad un filesystem.} +} +{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, + nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\errcode{ENOSYS}] il filesystem su cui si trova il file specificato non - supporta la funzione. - \end{errlist} - e \errval{EFAULT} ed \errval{EIO} per entrambe, \errval{EBADF} per - \func{fstatfs}, \errval{ENOTDIR}, \errval{ENAMETOOLONG}, \errval{ENOENT}, - \errval{EACCES}, \errval{ELOOP} per \func{statfs}.} -\end{functions} + \end{errlist} ed inoltre \errval{EFAULT} ed \errval{EIO} per entrambe, + \errval{EBADF} per \func{fstatfs}, \errval{ENOTDIR}, \errval{ENAMETOOLONG}, + \errval{ENOENT}, \errval{EACCES}, \errval{ELOOP} per \func{statfs} nel loro + significato generico.} +\end{funcproto} + Queste funzioni permettono di ottenere una serie di informazioni generali riguardo al filesystem su cui si trova il file specificato; queste vengono @@ -6769,10 +6814,16 @@ programmi e librerie) di cui il server potrebbe avere bisogno. % LocalWords: forced allowed sendmail SYSLOG WAKE ALARM CLOCK BOOTTIME dqstats % LocalWords: REALTIME securebits GETSTATS QFMT curspace curinodes btime itime % LocalWords: QIF BLIMITS bhardlimit bsoftlimit ILIMITS ihardlimit isoftlimit -% LocalWords: INODES LIMITS USAGE valid dqi IIF BGRACE bgrace IGRACE igrace +% LocalWords: INODES LIMITS USAGE valid dqi IIF BGRACE bgrace IGRACE igrace is % LocalWords: Python Truelite Srl quotamodule Repository who nell' dall' KEEP % LocalWords: SECURE KEEPCAPS prctl FIXUP NOROOT LOCKED dell'IPC dell'I IOPRIO -% LocalWords: CAPBSET CLASS IDLE dcookie overflow DIFFERS +% LocalWords: CAPBSET CLASS IDLE dcookie overflow DIFFERS Virtual everything +% LocalWords: dentry register resolution cache dcache operation llseek poll +% LocalWords: multiplexing fsync fasync seek block superblock gapil tex img +% LocalWords: second linked journaled source filesystemtype unsigned device +% LocalWords: mountflags NODEV ENXIO dummy devfs magic MGC RDONLY NOSUID MOVE +% LocalWords: NOEXEC SYNCHRONOUS REMOUNT MANDLOCK NODIRATIME umount MNT statfs +% LocalWords: fstatfs fstab mntent ino bound orig new setpcap %%% Local Variables: %%% mode: latex diff --git a/gapil.tex b/gapil.tex index b237d38..378cc51 100644 --- a/gapil.tex +++ b/gapil.tex @@ -97,9 +97,9 @@ hyperfootnotes=false]{hyperref} \makeindex % Solo prima parte, scommentare -%\includeonly{macro,preambolo,pref,intro,process,prochand,fileintro,filedir, -% fileunix,filestd,system,system,signal,session,fileadv,ipc,errors, -% ringraziamenti,fdl} +% \includeonly{macro,preambolo,pref,intro,process,prochand,filedir, +% fileunix,filestd,system,signal,session,fileadv,ipc,errors, +% ringraziamenti,fdl} % Solo seconda parte e appendici, scommentare %\includeonly{macro,preambolo,network,socket,tcpsock,sockctrl,othersock, diff --git a/img/dir_links.dia b/img/dir_links.dia index 7b0faf1..c378a1a 100644 Binary files a/img/dir_links.dia and b/img/dir_links.dia differ diff --git a/img/dir_struct.dia b/img/dir_struct.dia index 0c8dd86..6dfaf98 100644 Binary files a/img/dir_struct.dia and b/img/dir_struct.dia differ diff --git a/img/disk_struct.dia b/img/disk_struct.dia index 0c248c1..977b794 100644 Binary files a/img/disk_struct.dia and b/img/disk_struct.dia differ diff --git a/img/endianness.dia b/img/endianness.dia index ca45c9e..99ba5b9 100644 Binary files a/img/endianness.dia and b/img/endianness.dia differ diff --git a/img/exec_rel.dia b/img/exec_rel.dia index 79c54ec..fd76c3d 100644 Binary files a/img/exec_rel.dia and b/img/exec_rel.dia differ diff --git a/img/fileperm.dia b/img/fileperm.dia index 47b6ee8..e6a24a5 100644 Binary files a/img/fileperm.dia and b/img/fileperm.dia differ diff --git a/img/filesys_struct.dia b/img/filesys_struct.dia index c08ed10..a16de8a 100644 Binary files a/img/filesys_struct.dia and b/img/filesys_struct.dia differ diff --git a/img/link_loop.dia b/img/link_loop.dia index 179491c..c5c011f 100644 Binary files a/img/link_loop.dia and b/img/link_loop.dia differ diff --git a/img/proc_beginend.dia b/img/proc_beginend.dia index 181bf26..692e3a2 100644 Binary files a/img/proc_beginend.dia and b/img/proc_beginend.dia differ diff --git a/img/struct_sys.dia b/img/struct_sys.dia index 64b5d95..2fe4685 100644 Binary files a/img/struct_sys.dia and b/img/struct_sys.dia differ diff --git a/img/vfs.dia b/img/vfs.dia index 1052b79..2e8cc8c 100644 Binary files a/img/vfs.dia and b/img/vfs.dia differ diff --git a/listati/file.h b/listati/file.h new file mode 100644 index 0000000..79065e6 --- /dev/null +++ b/listati/file.h @@ -0,0 +1,11 @@ +struct file { + ... + struct path f_path; + const struct file_operations *f_op; + ... + atomic_long_t f_count; + unsigned int f_flags; + fmode_t f_mode; + loff_t f_pos; + ... +}; diff --git a/process.tex b/process.tex index 8c7dc49..29f4234 100644 --- a/process.tex +++ b/process.tex @@ -1262,14 +1262,14 @@ il suo prototipo è: {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} - \item[\errcode{ENOMEM}] o \param{addr} + \param{length} eccede la dimensione - della memoria usata dal processo o l'intervallo di indirizzi specificato - non è mappato. - \item[\errcode{EINVAL}] \param{addr} non è un multiplo delle dimensioni di - una pagina. - \item[\errcode{EFAULT}] \param{vec} punta ad un indirizzo non valido. \item[\errcode{EAGAIN}] il kernel è temporaneamente non in grado di fornire una risposta. + \item[\errcode{EFAULT}] \param{vec} punta ad un indirizzo non valido. + \item[\errcode{EINVAL}] \param{addr} non è un multiplo delle dimensioni di + una pagina. + \item[\errcode{ENOMEM}] o \param{addr}$+$\param{length} eccede la dimensione + della memoria usata dal processo o l'intervallo di indirizzi specificato + non è mappato. \end{errlist}} \end{funcproto} @@ -1393,11 +1393,11 @@ singole sezioni di memoria sono rispettivamente \funcd{mlock} e {Entrambe le funzioni ritornano $0$ in caso di successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} + \item[\errcode{EINVAL}] \param{len} non è un valore positivo. \item[\errcode{ENOMEM}] alcuni indirizzi dell’intervallo specificato non corrispondono allo spazio di indirizzi del processo o si è superato il limite di \const{RLIMIT\_MEMLOCK} per un processo non privilegiato (solo per kernel a partire dal 2.6.9). - \item[\errcode{EINVAL}] \param{len} non è un valore positivo. \item[\errcode{EPERM}] il processo non è privilegiato (per kernel precedenti il 2.6.9) o si ha un limite nullo per \const{RLIMIT\_MEMLOCK} e il processo non è privilegiato (per kernel a partire dal 2.6.9). @@ -1521,8 +1521,8 @@ rispettivi prototipi sono: caso di successo e \val{NULL} in caso di errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} - \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'allocazione. \item[\errcode{EINVAL}] \param{boundary} non è una potenza di due. + \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'allocazione. \end{errlist}} \end{funcproto} @@ -1553,9 +1553,9 @@ prototipo è: caso di successo e \val{NULL} in caso di errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} - \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'allocazione. \item[\errcode{EINVAL}] \param{alignment} non è potenza di due e multiplo di \code{sizeof(void *)}. + \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'allocazione. \end{errlist}} \end{funcproto} @@ -2116,10 +2116,10 @@ suo prototipo è: {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} - \item[\errcode{ENOMEM}] non c'è memoria sufficiente per aggiungere una nuova - variabile all'ambiente. \item[\errcode{EINVAL}] \param{name} è \val{NULL} o una stringa di lunghezza nulla o che contiene il carattere ``\texttt{=}''. + \item[\errcode{ENOMEM}] non c'è memoria sufficiente per aggiungere una nuova + variabile all'ambiente. \end{errlist}} \end{funcproto} diff --git a/prochand.tex b/prochand.tex index 5c6a408..8661b30 100644 --- a/prochand.tex +++ b/prochand.tex @@ -960,10 +960,10 @@ comportamento di \func{wait}\footnote{in effetti il codice processo non è uscito e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} - \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e - la funzione è stata interrotta da un segnale. \item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o non è figlio del processo chiamante. + \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e + la funzione è stata interrotta da un segnale. \item[\errcode{EINVAL}] si è specificato un valore non valido per l'argomento \param{options}. \end{errlist}} @@ -1214,10 +1214,10 @@ suo prototipo è: {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} - \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e - la funzione è stata interrotta da un segnale. \item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o non è figlio del processo chiamante. + \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e + la funzione è stata interrotta da un segnale. \item[\errcode{EINVAL}] si è specificato un valore non valido per l'argomento \param{options}. \end{errlist}} @@ -1391,27 +1391,25 @@ prototipo è: eseguibili, o il file è su un filesystem montato con l'opzione \cmd{noexec}, o manca il permesso di attraversamento di una delle directory del pathname. - \item[\errcode{EPERM}] il file ha i bit \itindex{suid~bit} \acr{suid} o - \itindex{sgid~bit} \acr{sgid} e l'utente non è root, ed il processo viene - tracciato, oppure il filesystem è montato con l'opzione \cmd{nosuid}. + \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento + \const{PF\_INTERP}, cioè chiede di essere eseguito da più di un + interprete. + \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato + riconoscibile. \item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non riconosciuto come tale, o compilato per un'altra architettura. \item[\errcode{ENOENT}] il file o una delle librerie dinamiche o l'interprete necessari per eseguirlo non esistono. + \item[\errcode{EPERM}] il file ha i bit \itindex{suid~bit} \acr{suid} o + \itindex{sgid~bit} \acr{sgid} e l'utente non è root, ed il processo viene + tracciato, oppure il filesystem è montato con l'opzione \cmd{nosuid}. \item[\errcode{ETXTBSY}] l'eseguibile è aperto in scrittura da uno o più processi. - \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento - \const{PF\_INTERP}, cioè chiede di essere eseguito da più di un - interprete. - \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato - riconoscibile. \item[\errcode{E2BIG}] la lista degli argomenti è troppo grande. \end{errlist} - ed inoltre \errval{EFAULT}, \errval{ENOMEM}, - \errval{EIO}, \errval{ENAMETOOLONG}, \errval{ELOOP}, \errval{ENOTDIR}, - \errval{EISDIR}, \errval{ENFILE}, \errval{EMFILE} nel loro significato - generico. -} + ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{EISDIR}, \errval{ELOOP}, + \errval{EMFILE}, \errval{ENAMETOOLONG}, \errval{ENFILE}, \errval{ENOMEM}, + \errval{ENOTDIR} nel loro significato generico. } \end{funcproto} La funzione \func{execve} esegue il programma o lo script indicato dal @@ -2224,9 +2222,9 @@ il suo prototipo è: caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido. -\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore. \item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore massimo consentito di gruppi supplementari. +\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore. \end{errlist}} \end{funcproto} @@ -2248,9 +2246,9 @@ un utente specifico, si può usare \funcd{initgroups} il cui prototipo è: {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} -\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore. \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare lo spazio per informazioni dei gruppi. +\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore. \end{errlist}} \end{funcproto} @@ -2537,10 +2535,10 @@ funzione \funcd{getpriority}, derivata da BSD; il suo prototipo è: {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} -\item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di - \param{which} e \param{who}. \item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli elencati in tab.~\ref{tab:proc_getpriority}. +\item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di + \param{which} e \param{who}. \end{errlist}} \end{funcproto} @@ -2599,14 +2597,14 @@ impostare la priorità di uno o più processi; il suo prototipo è: {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} +\item[\errcode{EACCES}] si è richiesto un aumento di priorità senza avere + sufficienti privilegi. +\item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli + elencati in tab.~\ref{tab:proc_getpriority}. +\item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha + cercato di modificare la priorità di un processo di un altro utente. \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di \param{which} e \param{who}. -\item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli - elencati in tab.~\ref{tab:proc_getpriority}. - \item[\errcode{EACCES}] si è richiesto un aumento di priorità senza avere - sufficienti privilegi. - \item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha - cercato di modificare la priorità di un processo di un altro utente. \end{errlist}} \end{funcproto} @@ -2739,11 +2737,11 @@ ordinarie o viceversa, che di specificare, in caso di politiche {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} - \item[\errcode{ESRCH}] il processo \param{pid} non esiste. \item[\errcode{EINVAL}] il valore di \param{policy} non esiste o il relativo valore di \param{p} non è valido per la politica scelta. \item[\errcode{EPERM}] il processo non ha i privilegi per attivare la politica richiesta. + \item[\errcode{ESRCH}] il processo \param{pid} non esiste. \end{errlist}} \end{funcproto} @@ -2906,14 +2904,14 @@ prototipi sono: \fdecl{int sched\_getparam(pid\_t pid, struct sched\_param *param)} \fdesc{Legge la priorità statica di un processo.} } -{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual +{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} -\item[\errcode{ESRCH}] il processo \param{pid} non esiste. \item[\errcode{EINVAL}] il valore di \param{param} non ha senso per la politica usata dal processo. \item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire l'operazione. +\item[\errcode{ESRCH}] il processo \param{pid} non esiste. \end{errlist}} \end{funcproto} @@ -2945,9 +2943,9 @@ prototipo è: {La funzione ritorna la politica di \textit{scheduling} in caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} - \item[\errcode{ESRCH}] il processo \param{pid} non esiste. \item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire l'operazione. + \item[\errcode{ESRCH}] il processo \param{pid} non esiste. \end{errlist}} \end{funcproto} @@ -2970,10 +2968,10 @@ il suo prototipo è: {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} -\item[\errcode{ESRCH}] il processo \param{pid} non esiste. \item[\errcode{EINVAL}] l'argomento \param{pid} non è valido. \item[\errcode{ENOSYS}] la \textit{system call} non è presente (solo per kernel arcaici). +\item[\errcode{ESRCH}] il processo \param{pid} non esiste. \end{errlist} ed inoltre anche \errval{EFAULT} nel suo significato generico.} \end{funcproto} @@ -3105,11 +3103,11 @@ funzione di libreria è \funcd{sched\_setaffinity} ed il suo prototipo è: {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} -\item[\errcode{ESRCH}] il processo \param{pid} non esiste. \item[\errcode{EINVAL}] il valore di \param{mask} contiene riferimenti a processori non esistenti nel sistema o a cui non è consentito l'accesso. \item[\errcode{EPERM}] il processo non ha i privilegi sufficienti per eseguire l'operazione. +\item[\errcode{ESRCH}] il processo \param{pid} non esiste. \end{errlist} ed inoltre anche \errval{EFAULT} nel suo significato generico.} \end{funcproto} @@ -3326,9 +3324,9 @@ cui prototipo è: {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} -\item[\errcode{ESRCH}] il processo \param{pid} non esiste. \item[\errcode{EINVAL}] \param{setsize} è più piccolo delle dimensioni della maschera di affinità usata dal kernel. +\item[\errcode{ESRCH}] il processo \param{pid} non esiste. \end{errlist} ed inoltre anche \errval{EFAULT} nel suo significato generico.} \end{funcproto} @@ -3406,11 +3404,11 @@ prototipi sono: successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} -\item[\errcode{ESRCH}] non esiste un processo corrispondente alle indicazioni. \item[\errcode{EINVAL}] i valori di \param{which} o di \param{ioprio} non sono validi. \item[\errcode{EPERM}] non si hanno i privilegi per eseguire l'impostazione (solo per \func{ioprio\_set}). +\item[\errcode{ESRCH}] non esiste un processo corrispondente alle indicazioni. \end{errlist}} \end{funcproto}