sarebbe altro che la lettura degli stessi su un buffer seguita dalla
relativa scrittura, cosa che in questo caso si dovrebbe eseguire con due
chiamate a \func{splice}.} In realtà le due system call sono profondamente
-diverse nel loro meccanismo di funzionamento; \func{sendfile} infatti, come
-accennato, non necessita affatto di avere a disposizione un buffer interno,
-perché esegue un trasferimento diretto di dati; questo la rende in generale
-molto più efficiente, ma anche limitata nelle sue applicazioni, dato che
-questo tipo di trasferimento è possibile solo in casi specifici.\footnote{e
- nel caso di Linux questi sono anche solo quelli in cui essa può essere
- effettivamente utilizzata.}
+diverse nel loro meccanismo di funzionamento;\footnote{questo fino al kernel
+ 2.6.23, dove \func{sendfile} è stata reimplementata in termini di
+ \func{splice}, pur mantenendo disponibile la stessa interfaccia verso l'user
+ space.} \func{sendfile} infatti, come accennato, non necessita di avere a
+disposizione un buffer interno, perché esegue un trasferimento diretto di
+dati; questo la rende in generale più efficiente, ma anche limitata nelle sue
+applicazioni, dato che questo tipo di trasferimento è possibile solo in casi
+specifici.\footnote{e nel caso di Linux questi sono anche solo quelli in cui
+ essa può essere effettivamente utilizzata.}
Il concetto che sta dietro a \func{splice} invece è diverso,\footnote{in
realtà la proposta originale di Larry Mc Voy non differisce poi tanto negli
% TODO documentare \func{fallocate}, introdotta con il 2.6.23
% vedi http://lwn.net/Articles/226710/ e http://lwn.net/Articles/240571/
-
+% http://kernelnewbies.org/Linux_2_6_23
%\subsection{L'utilizzo delle porte di I/O}
%\label{sec:file_io_port}
questa funzione ritorna sempre un valore di 150 millisecondi, e non importa
specificare il PID di un processo reale.
-
Come accennato ogni processo che usa lo scheduling real-time può rilasciare
volontariamente la CPU; questo viene fatto attraverso la funzione
\funcd{sched\_yield}, il cui prototipo è:
in modalità \textit{fifo}, per permettere l'esecuzione degli altri processi
con pari priorità quando la sezione più urgente è finita.
+% TODO: con il 2.6.23 il comportamento è stato leggermente modificato ed è
+% stato introdotto /proc/sys/kernel/sched_compat_yield da mettere a 1 per aver
+% la compatibilità con il precedente.
-\subsection{Il controllo dello \textit{scheduler} per i sistemi multiprocessore}
+\subsection{Il controllo dello \textit{scheduler} per i sistemi
+ multiprocessore}
\label{sec:proc_sched_multiprocess}
Infine con il supporto dei sistemi multiprocessore sono state introdotte delle