La richiesta di un \textit{file lock} prevede una scansione della lista per
determinare se l'acquisizione è possibile, ed in caso positivo l'aggiunta di
-un nuovo elemento.\footnote{cioè una nuova struttura \struct{file\_lock}.}
+un nuovo elemento.\footnote{cioè una nuova struttura \kstruct{file\_lock}.}
Nel caso dei blocchi creati con \func{flock} la semantica della funzione
prevede che sia \func{dup} che \func{fork} non creino ulteriori istanze di un
\textit{file lock} quanto piuttosto degli ulteriori riferimenti allo
stesso. Questo viene realizzato dal kernel secondo lo schema di
fig.~\ref{fig:file_flock_struct}, associando ad ogni nuovo \textit{file lock}
un puntatore\footnote{il puntatore è mantenuto nel campo \var{fl\_file} di
- \struct{file\_lock}, e viene utilizzato solo per i \textit{file lock} creati
+ \kstruct{file\_lock}, e viene utilizzato solo per i \textit{file lock} creati
con la semantica BSD.} alla voce nella \itindex{file~table} \textit{file
table} da cui si è richiesto il blocco, che così ne identifica il titolare.
kernel. Lo schema delle strutture utilizzate è riportato in
fig.~\ref{fig:file_posix_lock}; come si vede esso è molto simile all'analogo
di fig.~\ref{fig:file_flock_struct}:\footnote{in questo caso nella figura si
- sono evidenziati solo i campi di \struct{file\_lock} significativi per la
+ sono evidenziati solo i campi di \kstruct{file\_lock} significativi per la
semantica POSIX, in particolare adesso ciascuna struttura contiene, oltre al
\ids{PID} del processo in \var{fl\_pid}, la sezione di file che viene
bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}. La struttura è
Quando si richiede un \textit{file lock} il kernel effettua una scansione di
tutti i blocchi presenti sul file\footnote{scandisce cioè la
\itindex{linked~list} \textit{linked list} delle strutture
- \struct{file\_lock}, scartando automaticamente quelle per cui
+ \kstruct{file\_lock}, scartando automaticamente quelle per cui
\var{fl\_flags} non è \const{FL\_POSIX}, così che le due interfacce restano
ben separate.} per verificare se la regione richiesta non si sovrappone ad
una già bloccata, in caso affermativo decide in base al tipo di blocco, in
è attivo un blocco. Per questo motivo l'abilitazione del \textit{mandatory
locking} è di norma disabilitata, e deve essere attivata filesystem per
filesystem in fase di montaggio (specificando l'apposita opzione di
-\func{mount} riportata in sez.~\ref{sec:sys_file_config}), o con l'opzione
+\func{mount} riportata in sez.~\ref{sec:filesystem_mounting}), o con l'opzione
\code{-o mand} per il comando omonimo).
Si tenga presente inoltre che il \textit{mandatory locking} funziona solo
chiamate devono essere ripetute per ciascun file descriptor, incorrendo in
una perdita di prestazioni qualora il numero di file descriptor sia molto
grande; per questo è stato proposto di introdurre come estensione una
- funzione \func{epoll\_ctlv} che consenta di effettuare con una sola chiamata
+ funzione \code{epoll\_ctlv} che consenta di effettuare con una sola chiamata
le impostazioni per un blocco di file descriptor.} L'uso di
\const{EPOLL\_CTL\_MOD} consente in seguito di modificare le modalità di
osservazione di un file descriptor che sia già stato aggiunto alla lista di
osservazione.
+% TODO verificare se prima o poi epoll_ctlv verrà introdotta
+
Le impostazioni di default prevedono che la notifica degli eventi richiesti
sia effettuata in modalità \textit{level triggered}, a meno che sul file
descriptor non si sia impostata la modalità \textit{edge triggered},
versioni diverse della \textit{system call}; una prima versione,
\func{signalfd}, introdotta nel kernel 2.6.22 e disponibile con le
\acr{glibc} 2.8 che non supporta l'argomento \texttt{flags}, ed una seconda
- versione, \func{signalfd4}, introdotta con il kernel 2.6.27 e che è quella
+ versione, \funcm{signalfd4}, introdotta con il kernel 2.6.27 e che è quella
che viene sempre usata a partire dalle \acr{glibc} 2.9, che prende un
argomento aggiuntivo \code{size\_t sizemask} che indica la dimensione della
maschera dei segnali, il cui valore viene impostato automaticamente dalle
In presenza di dati invece il programma proseguirà l'esecuzione stampando
(\texttt{\small 19--20}) il nome del segnale ottenuto all'interno della
-struttura \const{signalfd\_siginfo} letta in \var{siginf}\footnote{per la
+struttura \struct{signalfd\_siginfo} letta in \var{siginf}\footnote{per la
stampa si è usato il vettore \var{sig\_names} a ciascun elemento del quale
corrisponde il nome del segnale avente il numero corrispondente, la cui
definizione si è omessa dal codice di fig.~\ref{fig:fiforeporter_code_init}
Infine due campi \var{name} e \var{len} sono utilizzati soltanto quando
l'evento è relativo ad un file presente in una directory posta sotto
osservazione, in tal caso essi contengono rispettivamente il nome del file
-(come pathname relativo alla directory osservata) e la relativa dimensione in
-byte. Il campo \var{name} viene sempre restituito come stringa terminata da
-NUL, con uno o più zeri di terminazione, a seconda di eventuali necessità di
-allineamento del risultato, ed il valore di \var{len} corrisponde al totale
-della dimensione di \var{name}, zeri aggiuntivi compresi. La stringa con il
-nome del file viene restituita nella lettura subito dopo la struttura
-\struct{inotify\_event}; questo significa che le dimensioni di ciascun evento
-di \textit{inotify} saranno pari a \code{sizeof(\struct{inotify\_event}) +
- len}.
+(come \itindsub{pathname}{relativo} \textit{pathname} relativo alla directory
+osservata) e la relativa dimensione in byte. Il campo \var{name} viene sempre
+restituito come stringa terminata da NUL, con uno o più zeri di terminazione,
+a seconda di eventuali necessità di allineamento del risultato, ed il valore
+di \var{len} corrisponde al totale della dimensione di \var{name}, zeri
+aggiuntivi compresi. La stringa con il nome del file viene restituita nella
+lettura subito dopo la struttura \struct{inotify\_event}; questo significa che
+le dimensioni di ciascun evento di \textit{inotify} saranno pari a
+\code{sizeof(\struct{inotify\_event}) + len}.
Vediamo allora un esempio dell'uso dell'interfaccia di \textit{inotify} con un
semplice programma che permette di mettere sotto osservazione uno o più file e
partire dal kernel 2.6.30 sono state introdotte anche per l'\textsl{I/O
vettorizzato} le analoghe delle funzioni \func{pread} e \func{pwrite} (vedi
sez.~\ref{sec:file_read} e \ref{sec:file_write}); le due funzioni sono
-\funcd{preadv} e \func{pwritev} ed i rispettivi prototipi sono:\footnote{le
+\funcd{preadv} e \funcd{pwritev} ed i rispettivi prototipi sono:\footnote{le
due funzioni sono analoghe alle omonime presenti in BSD; le \textit{system
call} usate da Linux (introdotte a partire dalla versione 2.6.30)
utilizzano degli argomenti diversi per problemi collegati al formato a 64
\func{splice}, oppure nessuno dei file descriptor è una pipe, oppure si
è dato un valore a \param{off\_in} o \param{off\_out} ma il
corrispondente file è un dispositivo che non supporta la funzione
- \func{seek}.
+ \func{lseek}.
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
richiesta.
\item[\errcode{ESPIPE}] o \param{off\_in} o \param{off\_out} non sono
un'altra; \param{fd\_in} deve essere il capo in lettura della \textit{pipe}
sorgente e \param{fd\_out} il capo in scrittura della \textit{pipe}
destinazione; a differenza di quanto avviene con \func{read} i dati letti con
-\func{tee} da \func{fd\_in} non vengono \textsl{consumati} e restano
+\func{tee} da \param{fd\_in} non vengono \textsl{consumati} e restano
disponibili sulla \textit{pipe} per una successiva lettura (di nuovo per il
comportamento delle \textit{pipe} si veda sez.~\ref{sec:ipc_unix}). Al
momento\footnote{quello della stesura di questo paragrafo, avvenuta il Gennaio
projects / gapil.git / blobdiff