X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=system.tex;h=f2569bf90a08beaedfe5654b421cbfe5fd784a78;hp=629c48cf6ed0be6f57e0b56c1f7ffc1408d56872;hb=ff76d56c6a2c280cbe4f153173488871d7b12336;hpb=6e257bf71f9acd5839dbae72de3dc9523cfb47c9 diff --git a/system.tex b/system.tex index 629c48c..f2569bf 100644 --- a/system.tex +++ b/system.tex @@ -1,6 +1,6 @@ %% system.tex %% -%% Copyright (C) 2000-2006 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2007 Simone Piccardi. Permission is granted to %% copy, distribute and/or modify this document under the terms of the GNU Free %% Documentation License, Version 1.1 or any later version published by the %% Free Software Foundation; with the Invariant Sections being "Un preambolo", @@ -8,6 +8,7 @@ %% license is included in the section entitled "GNU Free Documentation %% License". %% + \chapter{La gestione del sistema, del tempo e degli errori} \label{cha:system} @@ -403,7 +404,7 @@ riportate in tab.~\ref{tab:sys_file_macro}. \const{LINK\_MAX} &8 & numero massimo di link a un file\\ \const{NAME\_MAX}& 14 & lunghezza in byte di un nome di file. \\ \const{PATH\_MAX}& 256 & lunghezza in byte di un - \itindex{pathname}\textit{pathname}.\\ + \itindex{pathname} \textit{pathname}.\\ \const{PIPE\_BUF}&4096 & byte scrivibili atomicamente in una pipe (vedi sez.~\ref{sec:ipc_pipes}).\\ \const{MAX\_CANON}&255 & dimensione di una riga di terminale in modo @@ -434,7 +435,7 @@ le analoghe di tab.~\ref{tab:sys_posix1_general}. \const{\_POSIX\_LINK\_MAX} &8 & numero massimo di link a un file.\\ \const{\_POSIX\_NAME\_MAX}& 14 & lunghezza in byte di un nome di file. \\ \const{\_POSIX\_PATH\_MAX}& 256 & lunghezza in byte di un - \itindex{pathname}\textit{pathname}.\\ + \itindex{pathname} \textit{pathname}.\\ \const{\_POSIX\_PIPE\_BUF}& 512 & byte scrivibili atomicamente in una pipe.\\ \const{\_POSIX\_MAX\_CANON}&255 & dimensione di una riga di @@ -477,12 +478,12 @@ E si noti come la funzione in questo caso richieda un argomento che specifichi a quale file si fa riferimento, dato che il valore del limite cercato può variare a seconda del filesystem. Una seconda versione della funzione, \funcd{fpathconf}, opera su un file descriptor invece che su un -\itindex{pathname}\textit{pathname}. Il suo prototipo è: +\itindex{pathname} \textit{pathname}. Il suo prototipo è: \begin{prototype}{unistd.h}{long fpathconf(int fd, int name)} Restituisce il valore del parametro \param{name} per il file \param{fd}. \bodydesc{È identica a \func{pathconf} solo che utilizza un file descriptor - invece di un \itindex{pathname}\textit{pathname}; pertanto gli errori + invece di un \itindex{pathname} \textit{pathname}; pertanto gli errori restituiti cambiano di conseguenza.} \end{prototype} \noindent ed il suo comportamento è identico a quello di \func{pathconf}. @@ -601,7 +602,7 @@ maniera gerarchica all'interno di un albero;\footnote{si tenga presente che occorrerà includere anche i file \file{linux/unistd.h} e \file{linux/sysctl.h}.} per accedere ad uno di essi occorre specificare un cammino attraverso i vari nodi dell'albero, in maniera analoga a come avviene -per la risoluzione di un \itindex{pathname}\textit{pathname} (da cui l'uso +per la risoluzione di un \itindex{pathname} \textit{pathname} (da cui l'uso alternativo del filesystem \file{/proc}, che vedremo dopo). Ciascun nodo dell'albero è identificato da un valore intero, ed il cammino che @@ -645,7 +646,7 @@ forma di file alcune delle strutture interne del kernel stesso. In particolare l'albero dei valori di \func{sysctl} viene presentato in forma di file nella directory \file{/proc/sys}, cosicché è possibile accedervi -specificando un \itindex{pathname}\textit{pathname} e leggendo e scrivendo sul +specificando un \itindex{pathname} \textit{pathname} e leggendo e scrivendo sul file corrispondente al parametro scelto. Il kernel si occupa di generare al volo il contenuto ed i nomi dei file corrispondenti, e questo ha il grande vantaggio di rendere accessibili i vari parametri a qualunque comando di shell @@ -701,7 +702,7 @@ sulla directory \param{target}. \textit{mount point} o di spostarlo quando \param{target} non è un \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 + 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}. @@ -767,7 +768,7 @@ valori riportati in tab.~\ref{tab:sys_mount_flags}. \hline \const{MS\_RDONLY} & 1 & monta in sola lettura.\\ \const{MS\_NOSUID} & 2 & ignora i bit \itindex{suid~bit} \acr{suid} e - \itindex{sgid~bit}\acr{sgid}.\\ + \itindex{sgid~bit} \acr{sgid}.\\ \const{MS\_NODEV} & 4 & impedisce l'accesso ai file di dispositivo.\\ \const{MS\_NOEXEC} & 8 & impedisce di eseguire programmi.\\ \const{MS\_SYNCHRONOUS}& 16 & abilita la scrittura sincrona.\\ @@ -949,7 +950,7 @@ dall'altra con il diffondersi delle reti la necessit informazioni degli utenti e dei gruppi per insiemi di macchine, in modo da mantenere coerenti i dati, ha portato anche alla necessità di poter recuperare e memorizzare dette informazioni su supporti diversi, introducendo il sistema -del \itindex{Name~Service~Switch}\textit{Name Service Switch} che tratteremo +del \itindex{Name~Service~Switch} \textit{Name Service Switch} che tratteremo brevemente più avanti (in sez.~\ref{sec:sock_resolver}) dato che la maggior parte delle sua applicazioni sono relative alla risoluzioni di nomi di rete. @@ -1083,7 +1084,7 @@ fig.~\ref{fig:sys_group_struct}. Le funzioni viste finora sono in grado di leggere le informazioni sia direttamente dal file delle password in \file{/etc/passwd} che tramite il -sistema del \itindex{Name~Service~Switch}\textit{Name Service Switch} e +sistema del \itindex{Name~Service~Switch} \textit{Name Service Switch} e sono completamente generiche. Si noti però che non c'è una funzione che permetta di impostare direttamente una password.\footnote{in realtà questo può essere fatto ricorrendo a PAM, ma questo è un altro discorso.} Dato che @@ -1381,7 +1382,7 @@ system call eseguite per conto del processo. Gli altri tre campi servono a quantificare l'uso della memoria virtuale\index{memoria~virtuale} e corrispondono rispettivamente al numero di -\textit{page fault}\itindex{page~fault} (vedi sez.~\ref{sec:proc_mem_gen}) +\itindex{page~fault} \textit{page fault} (vedi sez.~\ref{sec:proc_mem_gen}) avvenuti senza richiedere I/O su disco (i cosiddetti \textit{minor page fault}), a quelli che invece han richiesto I/O su disco (detti invece \textit{major page fault}) ed al numero di volte che il processo è stato @@ -1456,12 +1457,12 @@ fatto solo fino al valore del secondo, che per questo viene detto \textit{hard stack il processo riceverà un segnale di \const{SIGSEGV}. \\ \const{RLIMIT\_CORE} & La massima dimensione per di un file di - \textit{core dump}\itindex{core~dump} (vedi + \itindex{core~dump} \textit{core dump} (vedi sez.~\ref{sec:sig_prog_error}) creato nella terminazione di un processo; file di dimensioni maggiori verranno troncati a questo valore, mentre con un valore si bloccherà la creazione - dei \textit{core dump}\itindex{core~dump}.\\ + dei \itindex{core~dump} \textit{core dump}.\\ \const{RLIMIT\_CPU} & Il massimo tempo di CPU (vedi sez.~\ref{sec:sys_cpu_times}) che il processo può usare. Il superamento del limite corrente @@ -1548,7 +1549,7 @@ In generale il superamento di un limite corrente\footnote{di norma quanto dei due limiti.} comporta o l'emissione di un segnale o il fallimento della system call che lo ha provocato;\footnote{si nuovo c'è una eccezione per \const{RLIMIT\_CORE} che influenza soltanto la dimensione (o l'eventuale - creazione) dei file di \itindex{core~dump}\textit{core dump}.} per + creazione) dei file di \itindex{core~dump} \textit{core dump}.} per permettere di leggere e di impostare i limiti di utilizzo delle risorse da parte di un processo sono previste due funzioni, \funcd{getrlimit} e \funcd{setrlimit}, i cui prototipi sono: @@ -1603,7 +1604,7 @@ Nello specificare un limite, oltre a fornire dei valori specifici, si pu anche usare la costante \const{RLIM\_INFINITY} che permette di sbloccare l'uso di una risorsa; ma si ricordi che solo un processo con i privilegi di amministratore\footnote{per essere precisi in questo caso quello che serve è - la \itindex{capabilities}\textit{capability} \const{CAP\_SYS\_RESOURCE}.} + la \itindex{capabilities} \textit{capability} \const{CAP\_SYS\_RESOURCE}.} può innalzare un limite al di sopra del valore corrente del limite massimo ed usare un valore qualsiasi per entrambi i limiti. Si tenga conto infine che tutti i limiti vengono ereditati dal processo padre attraverso una \func{fork} @@ -1616,7 +1617,7 @@ attraverso una \func{exec} (vedi sez.~\ref{sec:proc_exec}). La gestione della memoria è già stata affrontata in dettaglio in sez.~\ref{sec:proc_memory}; abbiamo visto allora che il kernel provvede il -meccanismo della memoria virtuale\index{memoria~virtuale} attraverso la +meccanismo della \index{memoria~virtuale} memoria virtuale attraverso la divisione della memoria fisica in pagine. In genere tutto ciò è del tutto trasparente al singolo processo, ma in certi @@ -1624,7 +1625,7 @@ casi, come per l'I/O mappato in memoria (vedi sez.~\ref{sec:file_memory_map}) che usa lo stesso meccanismo per accedere ai file, è necessario conoscere le dimensioni delle pagine usate dal kernel. Lo stesso vale quando si vuole gestire in maniera ottimale l'interazione della memoria che si sta allocando -con il meccanismo della paginazione\index{paginazione}. +con il meccanismo della \index{paginazione} paginazione. Di solito la dimensione delle pagine di memoria è fissata dall'architettura hardware, per cui il suo valore di norma veniva mantenuto in una costante che @@ -1697,8 +1698,8 @@ Il suo prototipo \end{prototype} La funzione restituisce in ciascun elemento di \param{loadavg} il numero medio -di processi attivi sulla coda dello scheduler\itindex{scheduler}, calcolato su -diversi intervalli di tempo. Il numero di intervalli che si vogliono +di processi attivi sulla coda dello \itindex{scheduler} scheduler, calcolato +su diversi intervalli di tempo. Il numero di intervalli che si vogliono leggere è specificato da \param{nelem}, dato che nel caso di Linux il carico viene valutato solo su tre intervalli (corrispondenti a 1, 5 e 15 minuti), questo è anche il massimo valore che può essere assegnato a questo argomento. @@ -1822,7 +1823,7 @@ mantenuto dal sistema e non dall'orologio hardware del calcolatore. Anche il \itindex{process~time} \textit{process time} di solito si esprime in -secondi, ma provvede una precisione ovviamente superiore al \textit{calendar +secondi, ma fornisce una precisione ovviamente superiore al \textit{calendar time} (che è mantenuto dal sistema con una granularità di un secondo) e viene usato per tenere conto dei tempi di esecuzione dei processi. Per ciascun processo il kernel calcola tre tempi diversi: