+Questa funzione e la corrispondente \func{sched\_setaffinity} hanno una storia
+abbastanza complessa, la system call prevede l'uso di due ulteriori argomenti
+di tipo \texttt{unsigned int len} e \texttt{unsigned long *mask}, che
+corrispondono al fatto che la implementazione effettiva usa una semplice
+maschera binaria. Quando le funzioni vennero incluse nelle \acr{glibc}
+assunsero invece il prototipo appena mostrato. A complicare la cosa si
+aggiunge il fatto che nella versione 2.3.3 delle \acr{glibc} l'argomento
+\param{cpusetsize} è stato eliminato, per poi essere ripristinato nella
+versione 2.3.4.\footnote{pertanto se la vostra pagina di manuale non è
+ aggiornata, o usate quella particolare versione delle \acr{glibc}, potrete
+ trovare indicazioni diverse, il prototipo illustrato è quello riportato
+ nella versione corrente (maggio 2008) delle pagine di manuale e
+ corrispondente alla definizione presente in \file{sched.h}.}
+
+La funzione imposta, con l'uso del valore contenuto all'indirizzo
+\param{cpuset}, l'insieme dei processori sui quali deve essere eseguito il
+processo identificato tramite il valore passato in \param{pid}. Come in
+precedenza il valore nullo di \param{pid} indica il processo corrente. Per
+poter utilizzare questa funzione sono richiesti i privilegi di amministratore
+(è necessaria la capacità \const{CAP\_SYS\_NICE}) altrimenti essa fallirà con
+un errore di \errcode{EPERM}. Una volta impostata una maschera di affinità,
+questa viene ereditata attraverso una \func{fork}, in questo modo diventa
+possibile legare automaticamente un gruppo di processi ad un singolo
+processore.
+
+Nell'uso comune, almeno con i kernel della serie 2.6.x, l'uso di questa
+funzione non è necessario, in quanto è lo scheduler stesso che provvede a
+mantenere al meglio l'affinità di processore. Esistono però esigenze
+particolari, ad esempio quando un processo (o un gruppo di processi) è
+utilizzato per un compito importante (ad esempio per applicazioni real-time o
+la cui risposta è critica) e si vuole la massima velocità, con questa
+interfaccia diventa possibile selezionare gruppi di processori utilizzabili in
+maniera esclusiva. Lo stesso dicasi quando l'accesso a certe risorse (memoria
+o periferiche) può avere un costo diverso a seconda del processore, come
+avviene nelle architetture NUMA (\textit{Non-Uniform Memory Access}).
+
+Infine se un gruppo di processi accede alle stesse risorse condivise (ad
+esempio una applicazione con più \itindex{thread} \textit{thread}) può avere
+senso usare lo stesso processore in modo da sfruttare meglio l'uso della sua
+cache; questo ovviamente riduce i benefici di un sistema multiprocessore
+nell'esecuzione contemporanea dei \itindex{thread} \textit{thread}, ma in
+certi casi (quando i \itindex{thread} \textit{thread} sono inerentemente
+serializzati nell'accesso ad una risorsa) possono esserci sufficienti vantaggi
+nell'evitare la perdita della cache da rendere conveniente l'uso dell'affinità
+di processore.
+
+Per facilitare l'uso dell'argomento \param{cpuset} le \acr{glibc} hanno
+introdotto un apposito dato di tipo, \ctyp{cpu\_set\_t},\footnote{questa è una
+ estensione specifica delle \acr{glibc}, da attivare definendo la macro
+ \macro{\_GNU\_SOURCE}, non esiste infatti una standardizzazione per
+ questo tipo di interfaccia e POSIX al momento non prevede nulla al
+ riguardo.} che permette di identificare un insieme di processori. Il dato è
+una maschera binaria: in generale è un intero a 32 bit in cui ogni bit
+corrisponde ad un processore, ma dato che per architetture particolari il
+numero di bit di un intero può non essere sufficiente, è stata creata questa
+che è una interfaccia generica che permette di usare a basso livello un tipo
+di dato qualunque rendendosi indipendenti dal numero di bit e dalla loro
+disposizione.
+
+Questa interfaccia, oltre alla definizione del tipo di dato apposito, prevede
+anche una serie di macro di preprocessore per la manipolazione dello stesso,
+che consentono di svuotare un insieme, aggiungere o togliere un processore da
+esso o verificare se vi è già presente:
+\begin{functions}
+ \headdecl{sched.h}
+ \funcdecl{void \macro{CPU\_ZERO}(cpu\_set\_t *set)}
+ Inizializza l'insieme (vuoto).
+
+ \funcdecl{void \macro{CPU\_SET}(int cpu, cpu\_set\_t *set)}
+ Inserisce il processore \param{cpu} nell'insieme.
+
+ \funcdecl{void \macro{CPU\_CLR}(int cpu, cpu\_set\_t *set)}
+ Rimuove il processore \param{cpu} nell'insieme.
+
+ \funcdecl{int \macro{CPU\_ISSET}(int cpu, cpu\_set\_t *set)}
+ Controlla se il processore \param{cpu} è nell'insieme.
+\end{functions}
+
+Oltre a queste macro, simili alle analoghe usate per gli insiemi di file
+descriptor (vedi sez.~\ref{sec:file_select}) è definita la costante
+\const{CPU\_SETSIZE} che indica il numero massimo di processori che possono
+far parte dell'insieme, e che costituisce un limite massimo al valore
+dell'argomento \param{cpu}.
+
+In generale la maschera di affinità è preimpostata in modo che un processo
+possa essere eseguito su qualunque processore, se può comunque leggere il
+valore per un processo specifico usando la funzione
+\funcd{sched\_getaffinity}, il suo prototipo è:
+\begin{prototype}{sched.h}
+ {int sched\_getaffinity (pid\_t pid, unsigned int cpusetsize,
+ const cpu\_set\_t *cpuset)}
+ Legge la maschera di affinità del processo \param{pid}.
+
+ \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
+ nel qual caso \var{errno} può assumere i valori:
+ \begin{errlist}
+ \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
+ \item[\errcode{EFAULT}] il valore di \param{cpuset} non è un indirizzo
+ valido.
+ \end{errlist} }
+\end{prototype}
+
+La funzione restituirà all'indirizzo specificato da \param{cpuset} il valore
+della maschera di affinità del processo, così da poterla riutilizzare per una
+successiva reimpostazione. In questo caso non sono necessari privilegi
+particolari.
+
+È chiaro che queste funzioni per la gestione dell'affinità hanno significato
+soltanto su un sistema multiprocessore, esse possono comunque essere
+utilizzate anche in un sistema con un processore singolo, nel qual caso però
+non avranno alcun risultato effettivo.
+
+\itindend{scheduler}
+\itindend{CPU~affinity}
+
+
+\subsection{Le priorità per le operazioni di I/O}
+\label{sec:io_priority}
+
+A lungo l'unica priorità usata per i processi è stata quella relativa
+all'assegnazione dell'uso del processore. Ma il processore non è l'unica
+risorsa che i processi devono contendersi, un'altra, altrettanto importante
+per le prestazioni, è quella dell'accesso a disco. Per questo motivo sono
+stati introdotti diversi \textit{I/O scheduler} in grado di distribuire in
+maniera opportuna questa risorsa ai vari processi. Fino al kernel 2.6.17 era
+possibile soltanto decidere le politiche di gestione scegliendo un diverso
+\textit{I/O scheduler}
+
+
+%TODO trattare le priorità di I/O
+% vedi man ioprio_set e Documentation/block/ioprio.txt
+
+%TODO trattare le funzionalità per il NUMA
+% vedi man numa e le pagine di manuale relative
+% vedere anche dove metterle...