Messa sezione sulle {{{ioctl}}} per la gestione delle interfacce di
[gapil.git] / sockctrl.tex
index 778fd865bda0fac9aacf216cd1c50c421bacb4fd..5730bda7bba3ac62a862171d9dcecdbc30b2b00a 100644 (file)
@@ -3210,21 +3210,81 @@ processo che riceve i segnali) che si effettuano chiamando \func{ioctl} con
 \const{SIOCGPGRP} e \const{SIOCSPGRP}.
 
 
+\subsection{L'uso di \func{ioctl} per l'accesso ai dispositivi di rete}
+\label{sec:sock_ioctl_netdevice}
+
+Benché non strettamente attinenti alla gestione dei socket, vale la pena di
+trattare qui l'interfaccia di accesso a basso livello ai dispositivi di rete
+che viene appunto fornita attraverso la funzione \texttt{ioctl}. Questa non è
+attinente a carattestiche specifiche di un qualche protocollo, ma si applica a
+tutti i socket, indipendentemente dal tipo o famiglia dello stesso, e permette
+di impostare e rilevare le funzionalità delle interfacce di rete.
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \includestruct{listati/ifreq.h}
+  \end{minipage}
+  \caption{La struttura \structd{ifreq} utilizzata dalle \func{ioctl} per le
+    operazioni di controllo sui dispositivi di rete.}
+  \label{fig:iface_ifreq_struct}
+\end{figure}
+
+Tutte le operazioni di questo tipo utilizzano come terzo argomento di
+\func{ioctl} il puntatore ad una struttura \struct{ifreq}, la cui definizione
+è illustrata in fig.~\ref{fig:iface_ifreq_struct}. La struttura utililzza il
+primo campo, \var{ifr\_name} per mantenere il nome dell'interfaccia su cui si
+vuole operare (ad esempio \texttt{eth0}, \texttt{ppp0}, ecc.), restituisce i
+valori nel secondo campo, che è definito appunto come una \ctyp{union}.  Le
+costanti che identificano le operazioni disponibili sono le seguenti:
+\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
+\item[\const{SIOCGIFNAME}]  .
+\item[\const{SIOCGIFINDEX}] .
+\item[\const{SIOCGIFFLAGS}] .
+\item[\const{SIOCSIFFLAGS}] .
+\item[\const{SIOCGIFMETRIC}] .
+\item[\const{SIOCSIFMETRIC}] .
+\item[\const{SIOCGIFMTU}] .
+\item[\const{SIOCSIFMTU}] .
+\item[\const{SIOCGIFHWADDR}] .
+\item[\const{SIOCSIFHWADDR}] .
+\item[\const{SIOCSIFHWBROADCAST}] .
+\item[\const{SIOCGIFMAP}] .
+\item[\const{SIOCSIFMAP}] . 
+\item[\const{SIOCADDMULTI}] .
+\item[\const{SIOCDELMULTI}] .
+\item[\const{SIOCGIFTXQLEN}] .
+\item[\const{SIOCSIFTXQLEN}] .
+\item[\const{SIOCSIFNAME}] .
+\item[\const{SIOCGIFCONF}] .
+\end{basedescript}
+
+
+
 \subsection{L'uso di \func{ioctl} per i socket TCP e UDP}
 \label{sec:sock_ioctl_IP}
 
-Oltre alle caratteristiche che si possono impostare per i socket generici, la
+Non esistono operazioni specifiche per i socket IP in quanto tali,\footnote{a
+  parte forse \const{SIOCGIFCONF}, che però resta attinente alle proprietà
+  delle interfacce di rete, per cui l'abbiamo trattata in
+  sez.~\ref{sec:sock_ioctl_netdevice} insieme alle altre che comunque si
+  applicano anche ai socket IP.} mentre per i pacchetti di altri protocolli
+trasportati su IP, qualora li si gestisca attraverso dei socket, si dovrà fare
+riferimento direttamente all'eventuale supporto presente per il tipo di socket
+usato: ad esempio si possono ricevere pacchetti ICMP con socket di tipo
+\texttt{raw}, nel qual caso si dovrà fare riferimento alle operazioni di
+quest'ultimo.
+
+Tuttavia la gran parte dei socket utilizzati nella programmazione di rete
+utilizza proprio il protocollo IP, e quello che succede è che in realtà la
 funzione \func{ioctl} consente di effettuare alcune operazioni specifiche per
-i socket UDP e TCP. Non esistono operazioni specifiche per i socket IP
-generici, mentre per i pacchetti di altri protocolli trasportati su IP,
-qualora li si gestisca attraverso dei socket, si dovrà fare riferimento
-direttamente all'eventuale supporto presente per il tipo di socket usato (ad
-esempio si possono ricevere pacchetti ICMP con socket di tipo \texttt{raw},
-nel qual caso si dovrà fare riferimento alle operazioni di quest'ultimo).
-
-Le operazioni di controllo disponibili per i socket TCP, come illustrate dalla
-relativa pagina di manuale, accessibile con \texttt{man 7 tcp}, prevedono come
-possibile valore per il secondo argomento della funzione dalle costanti
+i socket che usano questo protocollo, ma queste vendono eseguite, invece che a
+livello di IP, al successivo livello di trasporto, vale a dire in maniera
+specifica per i socket TCP e UDP.
+
+Le operazioni di controllo disponibili per i socket TCP sono illustrate dalla
+relativa pagina di manuale, accessibile con \texttt{man 7 tcp}, e prevedono
+come possibile valore per il secondo argomento della funzione le costanti
 illustrate nell'elenco seguente; il terzo argomento della funzione, gestito
 come \itindex{value~result~argument} \textit{value result argument}, deve
 essere sempre il puntatore ad una variabile di tipo \ctyp{int}:
@@ -3256,12 +3316,12 @@ essere sempre il puntatore ad una variabile di tipo \ctyp{int}:
   \errval{EINVAL}.
 \end{basedescript}
 
-Le operazioni di controllo disponibili per i socket UDP, come illustrate dalla
-relativa pagina di manuale, accessibile con \texttt{man 7 udp}, sono quelle
-indicate dalle costanti del seguente elenco; come per i socket TCP il terzo
-argomento viene gestito come \itindex{value~result~argument} \textit{value
-  result argument} e deve essere un puntatore ad una variabile di tipo
-\ctyp{int}:
+Le operazioni di controllo disponibili per i socket UDP, anch'esse illustrate
+dalla relativa pagina di manuale accessibile con \texttt{man 7 udp}, sono
+quelle indicate dalle costanti del seguente elenco; come per i socket TCP il
+terzo argomento viene gestito come \itindex{value~result~argument}
+\textit{value result argument} e deve essere un puntatore ad una variabile di
+tipo \ctyp{int}:
 \begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
 \item[\const{FIONREAD}] restituisce la dimensione in byte del primo pacchetto
   in attesa di ricezione, o 0 qualora non ci sia nessun pacchetto.