From cba678a2d4cdb82e16477812b1bef3e89cc1a7dd Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Tue, 5 Sep 2006 12:49:25 +0000 Subject: [PATCH] Messa sezione sulle {{{ioctl}}} per la gestione delle interfacce di rete, aggiunta relativa struttura e TODO per la funzione {{{sendfile}}}. --- fileadv.tex | 11 ++++-- listati/ifreq.h | 18 ++++++++++ sockctrl.tex | 94 ++++++++++++++++++++++++++++++++++++++++--------- 3 files changed, 104 insertions(+), 19 deletions(-) create mode 100644 listati/ifreq.h diff --git a/fileadv.tex b/fileadv.tex index e7b93dc..58c7ee6 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -1140,7 +1140,8 @@ Oltre alle precedenti modalit accesso ai file più evolute rispetto alle normali funzioni di lettura e scrittura che abbiamo esaminato in sez.~\ref{sec:file_base_func}. In questa sezione allora prenderemo in esame le interfacce per l'\textsl{I/O - vettorizzato} e per l'\textsl{I/O mappato in memoria}. + vettorizzato} e per l'\textsl{I/O mappato in memoria} e la funzione +\func{sendfile}. \subsection{I/O vettorizzato} @@ -1675,7 +1676,6 @@ una combinazione dei valori di tab.~\ref{tab:file_mmap_prot}. La nuova protezione verrà applicata a tutte le pagine contenute, anche parzialmente, dall'intervallo fra \param{addr} e \param{addr}+\param{size}-1. - Infine Linux supporta alcune operazioni specifiche non disponibili su altri kernel unix-like. La prima di queste è la possibilità di modificare un precedente \textit{memory mapping}, ad esempio per espanderlo o restringerlo. @@ -1851,6 +1851,13 @@ mappatura che gi % TODO l'I/O sulle porte di I/O % consultare le manpage di ioperm, iopl e outb +%\subsection{L'I/O diretto fra file descriptor con \func{sendfile}} +%\label{sec:file_sendfile} +% +% TODO documentare la funzione sendfile +% consultare la manpage di sendfile + + \section{Il file locking} \label{sec:file_locking} diff --git a/listati/ifreq.h b/listati/ifreq.h new file mode 100644 index 0000000..f7442c9 --- /dev/null +++ b/listati/ifreq.h @@ -0,0 +1,18 @@ +struct ifreq { + char ifr_name[IFNAMSIZ]; /* Interface name */ + union { + struct sockaddr ifr_addr; + struct sockaddr ifr_dstaddr; + struct sockaddr ifr_broadaddr; + struct sockaddr ifr_netmask; + struct sockaddr ifr_hwaddr; + short ifr_flags; + int ifr_ifindex; + int ifr_metric; + int ifr_mtu; + struct ifmap ifr_map; + char ifr_slave[IFNAMSIZ]; + char ifr_newname[IFNAMSIZ]; + char * ifr_data; + }; +}; diff --git a/sockctrl.tex b/sockctrl.tex index 778fd86..5730bda 100644 --- a/sockctrl.tex +++ b/sockctrl.tex @@ -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. -- 2.30.2