+
+
+
+\subsection{Considerazioni generali}
+\label{sec:ipc_sysv_generic}
+
+La principale caratteristica del sistema di IPC di System V è quella di essere
+basato su oggetti permanenti che risiedono nel kernel. Questi, a differenza di
+quanto avviene per i file descriptor, non mantengono un contatore dei
+riferimenti, e non vengono cancellati dal sistema una volta che non sono più
+in uso. Questo comporta che, al contrario di quanto avviene per pipe e fifo,
+la memoria allocata per questi oggetti non viene rilasciata automaticamente,
+ed essi devono essere cancellati esplicitamente, altrimenti resteranno attivi
+fino al riavvio del sistema.
+
+Gli oggetti usati nel System V IPC vengono creati direttamente dal kernel, e
+sono accessibili solo specificando il relativo \textsl{identificatore}. Questo
+è il numero progressivo che il kernel assengna a ciascuno di essi quanto
+vengono creati (il prodedimento è simile a quello con cui si assegna il
+\acr{pid} ai processi). L'identificatore viene restituito dalle funzioni che
+creano l'oggetto, ed è quindi locale al processo che le ha eseguite. Dato che
+l'identificatore viene assegnato dinamicamente dal kernel non è possibile
+prevedere quale sarà, ne utilizzare un qualche valore statico, si pone perciò
+il problema di come processi diversi possono accedere allo stesso oggetto.
+
+Per risolvere il problema il kernel associa a ciascun oggetto una struttura
+\var{ipc\_perm}; questa contiene una \textsl{chiave}, identificata da una
+variabile del tipo primitivo \type{key\_t}, che viene specificata in fase di
+creazione e tramite la quale è possibile ricavare l'identificatore. La
+struttura, la cui definizione è riportata in \figref{fig:ipc_ipc_perm},
+contiene anche le varie proprietà associate all'oggetto, come gli
+identificatori del creatore (\var{cuid} e \var{cgid}) e del proprietario
+(\var{uid} e \var{gid}), e le modalità di accesso (\var{mode}) che ne
+specifica i permessi, che sono analoghi a quelli usati per i file (vedi
+\secref{sec:file_perm_overview}).
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm ]{}
+struct ipc_perm
+{
+ key_t key; /* Key. */
+ uid_t uid; /* Owner's user ID. */
+ gid_t gid; /* Owner's group ID. */
+ uid_t cuid; /* Creator's user ID. */
+ gid_t cgid; /* Creator's group ID. */
+ unsigned short int mode; /* Read/write permission. */
+ unsigned short int seq; /* Sequence number. */
+};
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \var{ipc\_perm}, come definita in \file{sys/ipc.h}.}
+ \label{fig:ipc_ipc_perm}
+\end{figure}
+
+Usando la stessa chiave due processi diversi possono ricavare l'identificatore
+associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è
+come devono fare per accordarsi sull'uso di una stessa chiave. Se i processi
+sono \textsl{parenti} la soluzione è relativamente semplice, in tal caso
+infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un
+nuovo oggetto nel processo padre, l'idenficatore così ottenuto sarà
+disponibile in tutti i figli, e potrà essere passato come parametro attraverso
+una \func{exec}.
+
+Però quando i processi non sono \textsl{parenti} (come capita tutte le volte
+che si ha a che fare con un sistema client-server) tutto questo non è
+possibile; si potebbe comunque salvare l'identificatore su un file noto, ma
+questo ovviamente comporta lo svantaggio di doverselo andare a rileggere. Una
+alternativa più efficace è quella che i programmi usino un valore comune per
+la chiave (che ad esempio può essere dichiarato in un header comune), ma c'è
+sempre il rischio che questa chiave possa essere stata già utilizzata da
+qualcun altro. Dato che non esiste una convenzione su come assegnare queste
+chiavi in maniera univoca l'interfaccia mette a disposizione una funzione,
+\func{ftok}, che permette di ottenere una chiave specificando il nome di un
+file ed un numero di versione; il suo prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/ipc.h}
+
+ \funcdecl{key\_t ftok(const char *pathname, int proj\_id)}
+
+ Restituisce una chiave per identificare un oggetto del System V IPC.
+
+ \bodydesc{La funzione restituisce la chiave in caso di successo e -1
+ altrimenti, nel qual caso \var{errno} viene settata ad uno dei possibili
+ codici di errore di \func{stat}.}
+\end{functions}
+
+La funzione determina un valore della chiave sulla base di \param{pathname},
+che deve specificare il pathname di un file effettivamente esistente e di un
+numero di progetto \param{proj\_id)}, che di norma viene specificato come
+carattere, dato che ne vengono utilizzati solo gli 8 bit meno
+significativi.\footnote{nelle libc4 e libc5, come avviene in SunOS,
+ l'argomento \param{proj\_id)} è dichiarato tipo \ctyp{char}, le \acr{glibc}
+ han modificato il prototipo, ma vengono lo stesso utilizzati gli 8 bit meno
+ significativi.}
+
+Il problema è che anche così non c'è la sicurezza che il valore della chiave
+sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
+con i 16 bit meno significativi dell'inode del file \param{pathname} (che
+vengono ottenuti attraverso \func{stat}, da cui derivano i possibili errori),
+e gli 8 bit meno significativi del numero del device su cui è il file. Diventa
+perciò relativamente facile ottenere delle collisioni, specie se i file sono
+su dispositivi con lo stesso \textit{minor number}, come \file{/dev/hda1} e
+\file{/dev/sda1}.
+
+In genere quello che si fa è utilizzare un file comune usato dai programmi che
+devono comunicare (ad esempio un haeder, o uno dei programmi che devono usare
+l'oggetto in questione), utilizzando il numero di progetto per ottere le
+chiavi che interessano. In ogni caso occorre sempre controllare, prima di
+creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va
+bene in fase di creazione, le cose possono complicarsi per i programmi che
+devono solo accedere, in quanto, a parte gli eventuali controlli sugli altri
+attributi di \var{ipc\_perm}, non esiste una modalità semplice per essere
+sicuri della validità di una certa chiave.
+
+Questo è, insieme al fatto che gli oggetti sono permanenti e devono essere
+cancellati esplicitamente, il principale problema del sistema di IPC di System
+V. Non esiste infatti una modalità chiara per identificare un oggetto, come
+sarebbe stato se lo si fosse associato ad in file, e tutta l'interfaccia è
+inutilmente complessa. Per questo ne è stata effettuata una revisione
+completa nello standard POSIX.1b, che tratteremo in \secref{sec:ipc_posix}.
+