Altra documentazione sul log del kernel

diff --git a/session.tex b/session.tex
index 53a631db3f5e6023f3a9a24c2b21c9b8f4e574ad..f0827b0202393b650f5e677b4b0cc1cd77648ae0 100644 (file)
--- a/session.tex
+++ b/session.tex
@@ -750,16 +750,16 @@ Il sistema del \textit{syslog} attraverso il proprio demone di gestione
 provvede poi a riportare i messaggi all'amministratore attraverso una serie
 differenti meccanismi come:
 \begin{itemize*}
 provvede poi a riportare i messaggi all'amministratore attraverso una serie
 differenti meccanismi come:
 \begin{itemize*}

-\item scrivere sulla console.
-\item inviare via mail ad uno specifico utente.
-\item scrivere su un file (comunemente detto \textit{log file}).
-\item inviare ad un altro demone (anche via rete).
-\item scartare.
+\item scriverli sulla console.
+\item inviarli via mail ad uno specifico utente.
+\item scriverli su un file (comunemente detto \textit{log file}, o giornale).
+\item inviarli ad un altro demone (anche via rete su una macchina diversa).
+\item ignorarli completamente.

 \end{itemize*}
 \end{itemize*}

-le modalità dipendono ovviamente dal demone di gestione che si usa, per la
-gestione del quale si rimanda ad un testo di amministrazione di
-sistema.\footnote{l'argomento è ad esempio coperto dal capitolo 3.2.3 si
-  \cite{AGL}.}
+le modalità con cui queste azioni vengono realizzate dipendono ovviamente dal
+demone che si usa, per la gestione del quale si rimanda ad un testo di
+amministrazione di sistema.\footnote{l'argomento è ad esempio coperto dal
+  capitolo 3.2.3 si \cite{AGL}.}

 
 Le \acr{glibc} definiscono una serie di funzioni standard con cui un processo
 può accedere in maniera generica al servizio di \textit{syslog}, che però
 
 Le \acr{glibc} definiscono una serie di funzioni standard con cui un processo
 può accedere in maniera generica al servizio di \textit{syslog}, che però


@@ -935,7 +935,6 @@ Genera un messaggio di priorità \param{priority}.
 \bodydesc{La funzione non restituisce nulla.}
 \end{prototype}
 
 \bodydesc{La funzione non restituisce nulla.}
 \end{prototype}
 

-

 Per semplificare la gestione della scelta del livello di priorità a partire
 dal quale si vogliono registrare i messaggi, le funzioni di gestione
 mantengono per ogni processo una maschera che determina quale delle chiamate
 Per semplificare la gestione della scelta del livello di priorità a partire
 dal quale si vogliono registrare i messaggi, le funzioni di gestione
 mantengono per ogni processo una maschera che determina quale delle chiamate


@@ -949,7 +948,7 @@ funzione che consente di fare questo è \funcd{setlogmask}, ed il suo prototipo
 è:
 \begin{prototype}{syslog.h}{int setlogmask(int mask)}
 
 è:
 \begin{prototype}{syslog.h}{int setlogmask(int mask)}
 

-Imposta la maschera dei log al valore specificato.
+Imposta la maschera dei messaggi al valore specificato.

 
 \bodydesc{La funzione restituisce il precedente valore.}
 \end{prototype}
 
 \bodydesc{La funzione restituisce il precedente valore.}
 \end{prototype}


@@ -999,22 +998,24 @@ sono riportati in fig.~\ref{fig:printk_priority}
     \includestruct{listati/printk_prio.c}
   \end{minipage} 
   \normalsize 
     \includestruct{listati/printk_prio.c}
   \end{minipage} 
   \normalsize 

-  \caption{Definizione delle stringe coi relativi valori numerici che indicano
-    le priorità dei messaggi del kernel, ripresa da \texttt{linux/kernel.h}.}
+  \caption{Definizione delle stringhe coi relativi valori numerici che
+    indicano le priorità dei messaggi del kernel (ripresa da
+    \texttt{linux/kernel.h}).}

   \label{fig:printk_priority}
 \end{figure}
 
   \label{fig:printk_priority}
 \end{figure}
 

-Dato che i messaggi generati da \func{printk} hanno un loro specifico formato,
+Dato che i messaggi generati da \func{printk} hanno un loro specifico formato

 tradizionalmente si usava un demone ausiliario, \cmd{klogd}, per leggerli,
 rimappare le priorità sui valori di tab.~\ref{tab:sess_syslog_priority} e
 tradizionalmente si usava un demone ausiliario, \cmd{klogd}, per leggerli,
 rimappare le priorità sui valori di tab.~\ref{tab:sess_syslog_priority} e

-inviarli al sistema del \textit{syslog} nella facility \const{LOG\_KERN},
-anche se oggi i nuovi demoni che realizzano il servizio (come \texttt{rsyslog}
-o \texttt{syslog-ng}) sono in grado di fare tutto questo da soli.
+inviarli al sistema del \textit{syslog} nella facility \const{LOG\_KERN}.
+Oggi i nuovi demoni più avanzati che realizzano il servizio (come
+\texttt{rsyslog} o \texttt{syslog-ng}) sono in grado di fare tutto questo da
+soli.

 
 Ma i messaggi del kernel non sono necessariamente connessi al sistema del
 \textit{syslog}; ad esempio possono anche essere letti direttamente dal buffer
 
 Ma i messaggi del kernel non sono necessariamente connessi al sistema del
 \textit{syslog}; ad esempio possono anche essere letti direttamente dal buffer

-con il comando \texttt{dmesg}. Inoltre è previsto che essi vengano anche
-stampati direttamente sul terminale indicato come console di
+circolare con il comando \texttt{dmesg}. Inoltre è previsto che essi vengano
+stampati direttamente sul terminale indicato come \textit{console} di

 sistema,\footnote{quello che viene indicato con il parametro di avvio
   \texttt{console} del kernel, si consulti al riguardo sez.~5.3.1 di
   \cite{AGL}.} se superano una certa priorità, in modo che sia possibile
 sistema,\footnote{quello che viene indicato con il parametro di avvio
   \texttt{console} del kernel, si consulti al riguardo sez.~5.3.1 di
   \cite{AGL}.} se superano una certa priorità, in modo che sia possibile


@@ -1036,14 +1037,16 @@ Per la lettura dei messaggi del kernel e la gestione del relativo buffer
 circolare esiste una apposita \textit{system call} chiamata anch'essa
 \texttt{syslog}, ma dato il conflitto di nomi questa viene rimappata su
 un'altra funzione di libreria, in particolare nelle \acr{glibc} essa viene
 circolare esiste una apposita \textit{system call} chiamata anch'essa
 \texttt{syslog}, ma dato il conflitto di nomi questa viene rimappata su
 un'altra funzione di libreria, in particolare nelle \acr{glibc} essa viene

-invocata tramite la funzione \funcd{klogctl}, il cui prototipo è:
+invocata tramite la funzione \funcd{klogctl},\footnote{nelle \acr{libc4} e
+  nelle \acr{libc5} la funzione invece era \func{SYS\_klog}.} il cui prototipo
+è:

 \begin{prototype}{sys/klog.h}{int klogctl(int op, char *buffer, int len)}
 
 \begin{prototype}{sys/klog.h}{int klogctl(int op, char *buffer, int len)}
 

-Gestisce il buffer dei messaggi di log del kernel.
+Gestisce i messaggi di log del kernel.

 
 

-\bodydesc{La funzione restituisce un intero positivo dipendente
-  dall'operazione scelta o $-1$ in caso di errore, nel qual caso \var{errno}
-  assumerà i valori:
+\bodydesc{La funzione restituisce in caso di successo un intero positivo o
+  nullo dipendente dall'operazione scelta e $-1$ in caso di errore, nel qual
+  caso \var{errno} assumerà i valori:

   \begin{errlist}
   \item[\errcode{EINVAL}] l'argomento \param{op} non ha un valore valido.
   \item[\errcode{ERESTARTSYS}] l'operazione è stata interrotta da un segnale.
   \begin{errlist}
   \item[\errcode{EINVAL}] l'argomento \param{op} non ha un valore valido.
   \item[\errcode{ERESTARTSYS}] l'operazione è stata interrotta da un segnale.


@@ -1055,15 +1058,82 @@ Gestisce il buffer dei messaggi di log del kernel.
 }
 \end{prototype}
 
 }
 \end{prototype}
 

+La funzione prevede che si passi come primo argomento \param{op} un codice
+numerico che indica l'operazione richiesta, il secondo argomento deve essere,
+per le operazioni che compiono una lettura di dati, l'indirizzo del buffer su
+cui copiarli, mentre il terzo indica la lunghezza del buffer, quando questo è
+richiesto, oppure un valore numerico. L'effettivo uso di questi due argomenti
+dipende comunque dall'operazione richiesta, ma essi devono essere comunque
+specificati, anche quando non servono, nel qual caso verranno semplicemente
+ignorati.

 
 

+\begin{table}[htb]
+  \footnotesize
+  \centering
+  \begin{tabular}[c]{|l|p{10cm}|}
+    \hline
+    \textbf{Valore}& \textbf{Significato}\\
+    \hline
+    \hline
+    \texttt{0} & apre il log (attualmente non fa niente), \param{buffer}
+                 e \param{len} sono ignorati.\\
+    \texttt{1} & chiude il log (attualmente non fa niente), \param{buffer}
+                 e \param{len} sono ignorati.\\
+    \texttt{2} & legge \param{len} byte nel buffer \param{buffer} dal log dei
+                 messaggi.\\   
+    \texttt{3} & legge \param{len} byte nel buffer \param{buffer} dal buffer
+                 circolare dei messaggi.\\
+    \texttt{4} & legge \param{len} byte nel buffer \param{buffer} dal buffer
+                 circolare dei messaggi e lo svuota.\\
+    \texttt{5} & svuota il buffer circolare dei messaggi, \param{buffer}
+                 e \param{len} sono ignorati.\\
+    \texttt{6} & disabilita la stampa dei messaggi sulla console, \param{buffer}
+                 e \param{len} sono ignorati.\\
+    \texttt{7} & abilita la stampa dei messaggi sulla console, \param{buffer}
+                 e \param{len} sono ignorati.\\
+    \texttt{8} & imposta a \param{len} il livello dei messaggi stampati sulla
+                 console, \param{buffer} è ignorato.\\ 
+    \texttt{9} & ritorna il numero di byte da leggere presenti sul buffer di
+                 log, \param{buffer} e \param{len} sono ignorati.\\
+    \texttt{10}& ritorna la dimensione del buffer di log, \param{buffer}
+                 e \param{len} sono ignorati.\\
+\hline
+\end{tabular}
+\caption{Valori possibili per l'argomento \param{op} di \func{klogctl}.}
+\label{tab:klogctl_operation}
+\end{table}

 
 

-La lettura dei messaggi del kernel può avvenire direttamente da  
-
-
-Il funzionamento del kernel prevede anche che sia possibile indicare quali
-messaggi di \func{printk} devono essere stampati direttamente sulla console,
-con la possibilità di impostare
-
+Si sono riportati i possibili valori di \param{op}, con una breve spiegazione
+della relativa operazione e a come vengono usati gli altri due argomenti, in
+tab.~\ref{tab:klogctl_operation}. Come si può notare la funzione è una sorta
+di interfaccia comune usata per eseguire operazioni completamente diverse fra
+loro.
+
+L'operazione relativa al valore 2 \param{op} consente di leggere un messaggio
+dal cosiddetto \textit{log} del kernel. Eseguire questa operazione è
+equivalente ad eseguire una lettura dal file
+\procfile{/proc/kmsg}:\footnote{in realtà è vero l'opposto, è questa funzione
+  che viene eseguita quando si legge da questo file.} se non vi sono messaggi
+la funzione blocca in attesa di dati e ritorna soltanto quando questi
+diventino disponibili. In tal caso verranno letti \param{len} byte
+su \param{buffer} ed estratti dal log;\footnote{i dati del \textit{log} del
+  kernel cioè si possono leggere una volta sola, se più processi eseguono
+  l'operazione di lettura soltanto uno riceverà i dati, a meno che completata
+  la propria operazione di lettura non restino altri messaggi pendenti che a
+  questo punto potrebbero essere letti da un altro processo in attesa.} il
+valore di ritorno di \func{klogctl} corrisponderà al numero di byte ottenuti.
+
+Se invece si usa l'operazione 3 i dati vengono letti dal buffer circolare
+usato da \texttt{printk}, che mantiene tutti i messaggi stampati dal kernel
+fino al limite delle sue dimensioni, in questo caso i messaggi possono essere
+letti più volte. Usando invece l'operazione 4 si richiede, dopo aver fatto la
+lettura, di cancellare il buffer circolare, che risulterà vuoto ad una lettura
+successiva. Anche con queste operazioni \param{len} indica il numero di byte
+da leggere e \param{buffer} il buffer dover leggerli, e la funzione ritorna il
+numero di byte effettivamente letti.
+
+Le operazioni corrispondenti ai valori 6, 7 ed 8 fanno riferimento ai
+parametri del kernel gestiti con \procfile{/proc/sys/kernel/printk}